From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 31 23:26:17 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B436916A417 for ; Thu, 31 Jan 2008 23:26:17 +0000 (UTC) (envelope-from stsp@stsp.name) Received: from fallback-mx.in-berlin.de (fallback-mx.in-berlin.de [192.109.42.17]) by mx1.freebsd.org (Postfix) with ESMTP id 2EDDE13C467 for ; Thu, 31 Jan 2008 23:26:16 +0000 (UTC) (envelope-from stsp@stsp.name) Received: from einhorn.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by fallback-mx.in-berlin.de (8.14.1/8.13.6/Debian-1) with ESMTP id m0VKb8m8002817 for ; Thu, 31 Jan 2008 21:37:08 +0100 X-Envelope-From: stsp@stsp.name X-Envelope-To: Received: from stsp.name (ted.stsp.name [217.197.84.186]) (authenticated bits=128) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id m0VKb6hg021970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 31 Jan 2008 21:37:06 +0100 Received: from ted.stsp.name (localhost [127.0.0.1]) by stsp.name (8.14.2/8.14.2) with ESMTP id m0VKb58I035603 for ; Thu, 31 Jan 2008 21:37:05 +0100 (CET) (envelope-from stsp@ted.stsp.name) Received: (from stsp@localhost) by ted.stsp.name (8.14.2/8.14.2/Submit) id m0VKb5d6035602 for freebsd-hackers@freebsd.org; Thu, 31 Jan 2008 21:37:05 +0100 (CET) (envelope-from stsp) Date: Thu, 31 Jan 2008 21:37:05 +0100 From: Stefan Sperling To: freebsd-hackers@freebsd.org Message-ID: <20080131203705.GB1674@ted.stsp.name> Mail-Followup-To: freebsd-hackers@freebsd.org References: <78cb3d3f0801302245v2183c613t6ecdd9acebbe9ef7@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ftEhullJWpWg/VHq" Content-Disposition: inline In-Reply-To: <78cb3d3f0801302245v2183c613t6ecdd9acebbe9ef7@mail.gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 Subject: Re: [OT] Q: what would you choose for a VCS today X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2008 23:26:17 -0000 --ftEhullJWpWg/VHq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 31, 2008 at 08:45:55AM +0200, Adrian Penisoara wrote: > Hi, >=20 > Side-topic, if you bear with me: if you were to choose again what to use > as source revision control system (VCS) from today's offerings, what would > you choose to maintain FreeBSD's sources or a side-off project tracking > FreeBSD as base that would allow better teams cooperation and easy code > merging between projects/branches ? Finally a thread to vent about this topic :) I'd very much like to hear how others are doing this, please post, people, I'll read it all. Here's my take on it. I'm only talking about maintaining local changes, not what the FreeBSD project per se should use for change management, and also I don't really talk about working in a team but it's probably still relevant and might help: Don't _ever_ follow development(7) and try to maintain one or more custom branches inside a cvsup'd copy of the FreeBSD CVS repo. I've been down that road. It sucks. It really prevented me from getting any work done while waiting for hours on end for cvs to set a tag, do an update, a commit, let alone a merge. Every operation took ages and ages. With two branches, one based on RELENG_6 and CURRENT at the time, merging changes between the two was a major pain. CVS had so much overhead for me that using it made the whole point of doing version control fly out the window from, say, the 42nd floor. I've investigated quite a few options to maintain modifications to FreeBSD since, mainly to manage wake on lan patches (see http://stsp.name/w= ol/) but also local bug fixes I need for my system (e.g. enabling AIGLX does not lock up my 6.3 box so I can run compiz, see PR #114688). I'm quite serious about version control. In fact I'm a partial and (currently) paid committer for the subversion project, so I could even say that I'm involved in version control professionally. What I wanted instead of CVS sounds fairly simple to me: To maintain my local mods to FreeBSD I don't really care about the whole CVS history. I just need to be able to take a snapshot at some point, put it on a branch, and keep importing upstream changes incrementally to that branch from there on. So a vendor branch, but without any (or as little as possible) manual labour involved in updating it. I could not find any tool that does this properly among subversion, git, monotone and mercurial. That's not a big list, but I don't have time to try out version control systems all day. Also, proprietary VCS's were never considered (I also keep my freebsd kernels blob-free, call me a hippie or whatever if you want :P) Most tools seem to insist on trying to import the whole history of a CVS repository before they let you start doing any work in the newly converted repository. All conversion tools I've tried failed converting the FreeBSD repository. git-cvsimport fails after a few minutes because cvsps produces bad output when run on the FreeBSD repo. I reported this to the git developers and as a result they made git-cvsimport error out correctly, but did not fix the actual issue. The monotone built-in cvs converter segfaulted after running a whole day. The generic tailor VCS conversion tool failed as well -- I don't remember how, it errored out after running for a while. Even though I am subversion dev I did not try cvs2svn, because I wanted to take this as an opportunity to get my feet wet in another VCS. Mercurial failed to convert the repo, too, and there was no way of telling it not to try to import the whole history either. But its handbook describes interesting alternative approach to vendor branches: Patch queues. If you think you need a vendor branch, take a look at mercurial patch queues and consider if they might do the job just as well: "Managing change with Mercurial Queues": http://hgbook.red-bean.com/hgbookch12.html#x16-26700012 "Advanced uses of Mercurial Queues": http://hgbook.red-bean.com/hgbookch13.html#x17-30200013 I won't explain the details in this mail, as duplicating information =66rom the handbook is a waste of time, but I'll give you my opinion: Patch queues are quite powerful, and even though you end up versioning diffs instead of whole files, the patch queue provides a nice enough abstraction that makes maintaining local changes as comfortable as maintaining a vendor branch. A big plus is that you do not need to take an extra step to generate diffs to send upstream, because you already have the diffs right in your =2Ehg/patches directory. Conflict resolution works almost the same way as during a "normal" VCS's merge (whatever "normal" means in version control land :P), and as you get to incrementally make the patches in your queue apply again, you don't have to deal with a source tree full of all conflicts of a merge, but only with conflicts caused by a single patch at a time. Patch guards let you apply patches conditionally, this is where it gets interesting if you maintain changes for, say, RELENG_7 and CURRENT at the same time, and still want to version control your patches. You'd use two distinct source trees living in different mercurial repositor= ies, both of them using a clone of your patches repository, and guards to make only patches for the given FreeBSD version apply to a given tree. However, if you don't intend to push your changes upstream, a vendor branch might be a better solution, because this way you can manage more changes over a longer period of time (i.e. many changes made throughout many years). Patch queues are desinged around a more dynamic work flow with some or all of your changes going back upstream. Or the "open source way" if you want to call it that. So closed source shops might not find patch queues useful, but everyone else probably will. So these are the steps I've taken to set up a local FreeBSD source tree I can hack away on and version my changes: $ cvsup cvs-supfile # cvsup the whole repo to local disk (for speed) $ cvs -rRELENG_x co -P -d ~/freebsd-cvs src # checkout some FreeBSD branch $ rsync -av --exclude=3DCVS --exclude=3D.cvsignore ~/freebsd-cvs ~/freebsd-= hg # This copy is made so we don't intermix a mercurial repo with a cvs # working copy. even though you could probably do this but end up being # a bit cumbersome. DON'T pass the -C flag to rsync, the copy will miss # all files mentioned in .cvsignore files, such as the kernel configs! $ cd ~/freebsd-hg && hg init $ hg clone ~/freebsd-hg ~/freebsd-myhacks $ cd ~/freebsd-myhacks && hg qinit -c # initialise committable patch queue $ hq qnew 6.3/ifconfig.diff # start new a patch, not names can contain slashes which creates subdirectories in the patch area ## edit, compile, fix pesky errors, compile again, install, test $ hq qrefresh # store new patch in .hg/patches/ $ hq qcommit -m "ifconfig ifcap WOL changes backported to 6.3" # commit patch created by qrefresh into mercurial repo rooted at .hg/patches/ $ hq qnew 6.3/if_vr.diff # start another patch, this time for if_vr ## edit, compile, fix pesky errors, compile again, install, test $ hq qrefresh $ hq qcommit -m "WOL support for VIA driver backported to 6.3" =20 So far, this setup hasn't failed me, and the speed is several orders of magnitude higher than using CVS branches. --=20 stefan http://stsp.name PGP Key: 0xF59D25F0 --ftEhullJWpWg/VHq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAkeiMXAACgkQ5dMCc/WdJfCoswCgoe60WDUSVzVUKhvgNE1JbPT0 F/gAoODwbXurERJUtXjmfrNUnhiRWJHN =8XtC -----END PGP SIGNATURE----- --ftEhullJWpWg/VHq--