[OT] Q: what would you choose for a VCS today
stsp at stsp.name
Thu Jan 31 15:26:17 PST 2008
On Thu, Jan 31, 2008 at 08:45:55AM +0200, Adrian Penisoara wrote:
> 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/wol/)
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":
"Advanced uses of Mercurial Queues":
I won't explain the details in this mail, as duplicating information
from 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
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 repositories,
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=CVS --exclude=.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"
So far, this setup hasn't failed me, and the speed is several orders of
magnitude higher than using CVS branches.
http://stsp.name PGP Key: 0xF59D25F0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080131/db599718/attachment.pgp
More information about the freebsd-hackers