[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Using Subversion in Real Life; merging strategies?

From: Colin D Bennett <cbennett_at_radsoft.com>
Date: 2002-09-08 03:53:31 CEST

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm trying to find out what changes we'd have to make to our development
process if we switched to Subversion (which I hope to convince my colleagues
to do!).

I've used CVS, ClearCase (I'd rather die than use that POS again), and am
currently using a product called TrueCM at work but have been using
Subversion for several months for my personal projects and am extremely happy
with it. (Sure, it took my entire Saturday last week to figure out why the
new SVN wouldn't import my dump file, then get the svn-convert-2451 or
whatever it is branch compiled, and convert over the repository. But I
learned a lot.) I'd love to help with Subversion development, but I haven't
written more than a few hundred lines of C code in the last couple years. I'm
mostly a Java hacker these days. But is there a list of things that need to
be done, where I could get started?

But I digress. Let me describe how we operate at work, and maybe someone can
suggest how this might apply if we switched to subversion. We use the
branching/merging paradigm at work. Usually each developer has one branch
where all his/her work is done. Sometimes we'll create sub-branches for big
tasks or refactors. Our repository branches look like this:

Current ("stable" branch, Integration is promoted here every 2 weeks)
        Integration ("HEAD" branch)
                cdb (user branch)
                ccooley (...)
                kdrake (...)
                [...]

So we all work in our own branches. When we're ready to integrate with the
"HEAD" (which in this case is Integration), here's what I would do, as cdb:

  1. Take the "Integration Hat", a physical token (a plastic crown) :) which
functions as a mutex so no one messes with Integration while we're merging
  2. Make sure all my stuff is checked into the "cdb" branch.
  3. Merge the differences between Integration and cdb *into my workspace*.
With our current tool, TrueCM, merges are into my "working copy", in SVN
terms, and don't go into my cdb branch until I check them in.
  4. Fix any conflicts, make sure regression tests run, etc.
  5. Now check merged files in to cdb branch.
  6. "Promote" cdb to Integration, in TrueCM terms. This means that cdb and
Integration are exactly the same after this step.

I'd appreciate any description of how you use Subversion for branching, or
links to pages with tips on this. I was excited to find the Linux1394 page
this morning, which had the first actual description of how merging between
branches can be done.

BTW, (*Web Site suggestion*) I think it would be great to have a list of open
source projects that are using subversion. I can't understand why anyone
would want to use CVS anymore. I certainly won't ever touch it again. Except
that it's more accessible: it comes with more Linux distros, while Subversion
(until recently, perhaps) has required a bootstrap download, checkout
(extremely painful on my poor modem. Can we expect performance increases
here?), download of apr, httpd-2.0, compiling all of them, etc. I finally
made a nice little shell script that will update, build, and install the
latest subversion (only I can't find a way to automatically detect what
version of neon I need). It works out pretty nicely.

Cheers,
Colin
- --
Colin D. Bennett <cbennett@radsoft.com>
[ RADSoft: Rapid Engineering Specialists ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9eq2ehU94DiH2eqQRAvVGAJwOQZNMHZoN0sTRTbGcz/r90eQRFwCgg96/
ld6G9R9bfXoUknePNRuNJSA=
=qabv
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Sep 8 03:56:24 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.