Re: GIT and CVS

[Phil Muldoon <pmuldoon@redhat.com>]

"Joseph S. Myers" <joseph@codesourcery.com> writes:

> 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;

I agree on the branching, but I do not understand why GDB has to be
tagged/branched in tandem with other projects.  We survive OK with the
disparate GCC versions, as well as GLIBC and other close dependencies.


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

This really catches a lot of newbies out, myself included.

>
> * 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.

BFD is an important part of the GDB setup, no doubt it is.  But has
anyone (myself included), talked to the community about it?  Is there
any reason why BFD cannot be an external dependency?  GCC, as an
external dependency has far more radical design shifts, I think, than
BFD, and we cope just fine.


>> 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 think really, we need to understand the relationship with BFD more
deeply.  If we are such in lock-step, then I agree a dual effort should
be undertaken.  I'm not sure I truly understand why this dependency has
to be managed internally, over every other dependency that GDB has to
cope with to be built.

>> 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

From a metric point of view, yes your numbers point to your argument.
But 18 seconds in the real world? How do those numbers compare with CVS?
I think I want to divorce the argument with ChangeLogs.  That was
something, I regret, putting in.  If we have to put ChangeLogs with GIT
so be it, I can live with that.

>
> 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.

If we have to continue ChangeLogs, so be it.  I am willing to make that
concession.

Cheers,

Phil