Re: GIT and CVS

["Joseph S. Myers" <joseph@codesourcery.com>]

On Thu, 13 Oct 2011, Phil Muldoon wrote:

> "Joseph S. Myers" <joseph@codesourcery.com> writes:
> 
> > On Thu, 13 Oct 2011, Phil Muldoon wrote:
> >
> >> So why are we still on CVS?  I'm not a release manager, so I do not have
> >
> > Because the complications associated with having many projects in the same 
> > repository are a lot of work to disentangle, and it is a lot of work to do 
> > the conversion (including all the infrastructure scripts, user 
> > instructions etc.) for any one project.
> >
> > I think binutils+gdb is the right unit to aim for getting into a separate 
> > repository, as discussed in 
> > <http://gcc.gnu.org/ml/gcc/2011-03/msg00486.html>.
> 
> Ok, thanks for your response.  Beyond the reason why they were in the
> same repository for how many years, why do they still have to be?
> 
> I can understand that projects so closely involved need to be in
> lock-step in their release objectives, but with healthy communities for
> each project, do they need to be still?

I've given my arguments many times before in past threads.  In essence:

* normal operations (checkouts, updates, tagging etc.) should be done in 
the normal way for the relevant version control systems, and the 
non-transparency of various systems for grafting pieces from different 
repositories tends to rule those out;

* that a normal operation ("cvs update -d") doesn't work properly is one 
of the serious problems with the present system;

* commits affecting both BFD and its clients are normal operations.

So I think putting the BFD users together with BFD is right - but I think 
a separate master repository for the shared toplevel files is also right 
(with hooks in other repositories to check for attempts to commit changes 
to shared files - on the mainline - that aren't just merges from the 
separate master).  The alternative for toplevel is the DVCSly pure 
approach with all repositories equal and no one master, but I think that 
would work less well in practice.

> I think though, I am missing the point.  If GDB decides, on its own, to
> go with GIT, what happens to the other projects?  What are the outcomes?

Synchronizing BFD would be a great pain.  For the projects other than 
binutils, I think they could continue just fine if gdb+binutils moves out 
(though with more toplevel pain if proper procedures aren't set up for 
keeping toplevel in sync).

> I nearly decided to delete that line from the email as I did not want to
> dilute the arguments.  I wrote the ChangeLog parser for Eclipse as I found
> ChangeLogs tiresome to write when history basically replaced it.  I must
> admit, even when I hack on emacs, it is still a pain.  I'll continue to
> do it, if people find it useful.  However, git log is very, highly
> configurable.  The options are very broad.  And, as you can generate a
> git log from a local repository, the NFS thing should not be too
> difficult to overcome?

Even with local disk, git is much more I/O intensive.  I timed looking at 
logs from a glibc checkout on local disk:

$ time git log > /dev/null

real    0m18.324s
user    0m0.560s
sys     0m0.304s
$ time cat ChangeLog* > /dev/null

real    0m0.314s
user    0m0.000s
sys     0m0.012s

That's nearly 60 times slower.  And apart from I/O cost the point remains 
that it is useful to have this information in tarballs and ad hoc 
snapshots, separated from the version control system and possibly imported 
into another.  I'd be glad to *expand* ChangeLogs - add information about 
*why* changes were made to the existing *what* - and so make them more 
useful, but they are useful anyway.

-- 
Joseph S. Myers
joseph@codesourcery.com