This is the mail archive of the
mailing list for the GDB project.
Re: time to be serious about dropping CVS
On Wed, 22 Dec 2010, NightStrike wrote:
> On Wed, Dec 22, 2010 at 10:23 AM, Christopher Faylor
> <firstname.lastname@example.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
* 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
* 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
Joseph S. Myers