Re: time to be serious about dropping CVS

[Joel Brobecker <brobecker@adacore.com>]

> Just checking: is your task force still on target to have proposals by the 
> end of the year?  A report on progress would be good even if there aren't 
> full proposals yet.

I am a bit ashamed, but I have procrastinated :-(. I was introduced
a while ago to the "git cvsexportcommit" command, which effectively
allows me to work exclusively in git, thanks to our git mirror.
The only downsides at, the moment, are: The git mirror is only updated
every 30mins, and I need to do a CVS update before I push a commit
from git to CVS.  On the other hand of the equation, we have a number
of hurdles to face before a conversion can be started, and the problem
is that the hurdles are not all just technical (multiple projects sharing
portions of the same repository), but human as well (convincing people
to change).

So the balance of benefits versus effort made me give up a bit on
the idea, at least for now. For now, in order for this to happen,
we would have to change something in the way we either get the sources,
or in the way we build, or both.  We might also not be able to do
the transition just on our own, and that means coordination with
other projects, etc. Perhaps, as more git features appear, we might
be able to find a simpler way to transition, and that could be
the trigger for transition to really start...

One of the things that we could think about, is getting away from
our 'partial checkout' way of getting the sources. It's convenient,
but it is also makes us utterly dependent on CVS. I think there is
a simple solution to that:
 (1) Separate out the projects that could go on to live their lives
    on their own (Eg: expect, tcl, tck, winsup, rda, etc)
 (2) And for the remaining projects, either:
     (a) Share one large repository: We would have to change the way
         we configure or the "make" command we use to build;
     (b) Have our own set of sources, with synchronization issues
         (which if effectively the same as (1), really).
Option (1) is not strictly necessary for option (2a), but I think
it would be a good cleanup, and probably benficial to those projects
too - as they would be getting more freedom, I think. I just realized
for instance that dejagnu is no longer part of src/. It's under git,
now.

The problem is that you have to convince people that all these changes
are desirable, and that, I think, is more difficult than the technical
work itself...

-- 
Joel