On Wed, 22 Dec 2010, NightStrike wrote:

> On Wed, Dec 22, 2010 at 10:23 AM, Christopher Faylor
> <cgf-use-the-mailinglist-please@sourceware.org> wrote:
> > On Tue, Dec 21, 2010 at 02:20:38PM -0500, DJ Delorie wrote:
> >>
> >>Just my two cents:
> >>
> >>1. I really hate the way GIT works.  Yes, I use it often, no, I don't
> >>   seem to be getting used to it.
> >>
> >>2. If src/ is split up, keeping the toplevels and libiberty in sync will
> >>   be much harder.  I don't think I'm willing to sign up for that job.
> >
> > IMO, in a perfect world, there would be only one version of libiberty
> > and the top-level configury.
> >
> > cgf
> >
> 
> That's easy to do with svn and svn:externals

No solution I've ever seen suggested for this, including svn:externals and 
git submodules, counts as easy.  The basic requirements for being easy 
are:

* You can branch, or tag, GCC, or binutils, or GDB, or any other component 
including the library, using the native command for branching or tagging 
in that version control system, and thereby have a branch or tag wherein 
the affected subdirectories are also branched or tagged.  This applies to 
both remote branches and tags, and to local ones in a DVCS.

* Anyone with write access to any relevant component can do so, as well as 
being able to make ordinary changes to the library, and the normal 
commands for committing changes can be used, including for changes 
including both shared and non-shared files.

(I would add a further requirement "each project can choose its VCS 
independently", but that's not a matter of a solution being easy, it's a 
desire to avoid in future one of the two things that has made it so hard 
for the projects in src to move away from CVS.  One is tying independently 
maintained projects too closely together; the other is making use of a 
feature, CVS modules, that is too specific to a single VCS.)

When you get into special commands being needed to branch, tag or check in 
changes you get trouble and lose the advantages of familiarity with a VCS 
across multiple projects.  I think there are two sensible solutions for 
shared files:

* The DVCSly pure one: no master copy, people make changes in whichever 
project they are working on and they or someone else merges them to other 
copies as convenient.  This passes both my points above for being easy for 
normal contributors (at the expense of being hard for mergers).

* A single master repository for the shared files and directories, with 
all commits to those files in the trunk of the other repositories being 
forbidden by commit hooks unless they contain some magic string in the 
commit log to indicate they are merges from the master repository.  All 
people with write access to any affected project also given write access 
to this new master repository.  This passes my first point but fails the 
second.

-- 
Joseph S. Myers
joseph@codesourcery.com