From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11051 invoked by alias); 22 Dec 2010 16:48:15 -0000 Received: (qmail 10887 invoked by uid 22791); 22 Dec 2010 16:48:12 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,TW_CG,TW_SV,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 22 Dec 2010 16:48:07 +0000 Received: (qmail 29536 invoked from network); 22 Dec 2010 16:48:05 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 22 Dec 2010 16:48:05 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.72) (envelope-from ) id 1PVRrA-0001lt-9W; Wed, 22 Dec 2010 16:48:04 +0000 Date: Wed, 22 Dec 2010 16:48:00 -0000 From: "Joseph S. Myers" To: NightStrike cc: DJ Delorie , gdb@sourceware.org, Joel Brobecker , binutils@sources.redhat.com Subject: Re: time to be serious about dropping CVS In-Reply-To: Message-ID: References: <20101221032725.GS2618@adacore.com> <20101222152320.GD25087@ednor.casa.cgf.cx> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1152306461-1476634446-1293036484=:6746" Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-12/txt/msg00072.txt.bz2 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1152306461-1476634446-1293036484=:6746 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-length: 2994 On Wed, 22 Dec 2010, NightStrike wrote: > On Wed, Dec 22, 2010 at 10:23 AM, Christopher Faylor > 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. =A0Yes, I use it often, no, I don't > >> =A0 seem to be getting used to it. > >> > >>2. If src/ is split up, keeping the toplevels and libiberty in sync will > >> =A0 be much harder. =A0I don't think I'm willing to sign up for that j= ob. > > > > IMO, in a perfect world, there would be only one version of libiberty > > and the top-level configury. > > > > cgf > > >=20 > That's easy to do with svn and svn:externals No solution I've ever seen suggested for this, including svn:externals and= =20 git submodules, counts as easy. The basic requirements for being easy=20 are: * You can branch, or tag, GCC, or binutils, or GDB, or any other component= =20 including the library, using the native command for branching or tagging=20 in that version control system, and thereby have a branch or tag wherein=20 the affected subdirectories are also branched or tagged. This applies to=20 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= =20 being able to make ordinary changes to the library, and the normal=20 commands for committing changes can be used, including for changes=20 including both shared and non-shared files. (I would add a further requirement "each project can choose its VCS=20 independently", but that's not a matter of a solution being easy, it's a=20 desire to avoid in future one of the two things that has made it so hard=20 for the projects in src to move away from CVS. One is tying independently= =20 maintained projects too closely together; the other is making use of a=20 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= =20 changes you get trouble and lose the advantages of familiarity with a VCS=20 across multiple projects. I think there are two sensible solutions for=20 shared files: * The DVCSly pure one: no master copy, people make changes in whichever=20 project they are working on and they or someone else merges them to other=20 copies as convenient. This passes both my points above for being easy for= =20 normal contributors (at the expense of being hard for mergers). * A single master repository for the shared files and directories, with=20 all commits to those files in the trunk of the other repositories being=20 forbidden by commit hooks unless they contain some magic string in the=20 commit log to indicate they are merges from the master repository. All=20 people with write access to any affected project also given write access=20 to this new master repository. This passes my first point but fails the=20 second. --=20 Joseph S. Myers joseph@codesourcery.com= ---1152306461-1476634446-1293036484=:6746--