Re: What is keeping GDB in CVS ?

[Tom Tromey <tromey@redhat.com>]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

Daniel> The solution I'd like best, I think, is one with separate projects
Daniel> that makes it easy to manually or automatically sync revisions from
Daniel> the shared directories.  This may be nothing more than some clever
Daniel> push hooks, for instance to reject manual changes to bfd/ being pushed
Daniel> to the central gdb repository and to automatically propogate changes
Daniel> to bfd/ from binutils.  Anyone feeling inspired enough to build a
Daniel> proof-of-concept?

I meant to reply again on the binutils thread, but I'm super
distracted these days.

I researched it a bit and I believe that git doesn't provide a nice
way to solve the modules problem.  There are a couple promising
approaches but I think if you look closely they don't really work (in
one case the exact feature we need was never merged into git).

One idea I had is to have an "infrastructure" repository holding
top-level configure, plus libiberty and include.  Then, gcc, src,
cgen, cygwin, etc would simply merge from this repository.  And, we'd
have a rule: no local changes.

These kinds of merges are trivial, we do them all the time in archer
(archer's master branch tracks gdb's master branch this way).  You
could even automate them, if the no local change rule was enforced.

Finally, I think binutils+gdb should probably just be a single source
repository.  They share enough to warrant that, IMO.  I suspect the
disk space overhead is not large.

I have no idea what to do about insight.

The problem with this approach is that it is less convenient than what
we have now.  If you have a change that touches libiberty then you
need two separate commits.

I suppose this is basically what you're saying :-)

I guess some new version of svn solves the module problem.
But... after working with git for the last year, I used svn for a gcc
patch this week and I was surprised by how amazingly slow it now
feels.  I'd really prefer git by a large margin.

Tom