Actually, when I read that Subversion uses the unstable head model for
development, I winced a little bit. I've always used the stable head for
development.
In the stable head model, all developers develop off of a private branch and
not off of the head of the main branch. They do not merge their work onto
the main branch until they can guarantee that their code will make the
release more stable and better. In ClearCase parlance (since it works so
well with this method), you always build with /main/LATEST (the latest
version off of the main branch).
Developers check out code from /main/LATEST (what ClearCase calls the
Integration Stream) onto a private branch (or what ClearCase calls a
Development Stream). When they finish coding, they do a back merge (what
ClearCase calls a rebase) from /main/LATEST onto their private branch,
rebuild and test. If all goes well, they merge their work (or what ClearCase
calls a delivery) back onto /main/LATEST. Since 99% of the merging is done
on the developer's branch, the delivery usually goes pretty smooth.
The end result is that I know that whatever is on /main/LATEST is always
ready for build. (Or, at least in theory.)
I don't know if Subversion can support such a model since their merge
operation isn't all that sophisticated yet. However, it might work for your
organization since you only have a single developer per project. Have
developers create a "development" branch where they do their work. When
their work is ready for prime time, have them merge their stuff back onto
the trunk.
Either that, or have a "build" branch and let the developers work off of the
trunk. Then, when they finish, they can merge onto the build branch.
-----Original Message-----
From: Brass Tilde [mailto:brasstilde@insightbb.com]
Sent: Monday, May 02, 2005 2:06 PM
To: Subversion mailing list
Subject: "Floating" tags and automating the build process
In our environment, we have numerous developers, all of whom are pretty much
the sole responsible party for one or more applications for which we have
ongoing development. It's seldom that we have two developers working on the
same project.
One of the ways that we're tossing around to make it easier for our build
person to build our applications, before we get an automated build tool and
implement it, is to have so-called "floating" tags in the repository.
Basically, these would point to the latest safely buildable revision of the
application in question. As far as I can tell, this would require deleting
the existing contents of the directory in the repository that corresponds to
our "Dev" tag every time we wanted to "float" the tag, correct?
Our other option is to simply decree that the HEAD revision of each
project's /trunk be the safely buildable version, and have all development
handled either on a branch, which is merged to the trunk when stable, or in
the WC with only stable stuff being checked in.
Thoughts? Other ideas (that don't require we implement Ant, CruiseControl
or something right away, but assuming that we *will* be implementing
something along those lines at some point)?
"Creationists make it sound as though a 'theory' is something you dreamt
up after being drunk all night." -Isaac Asimov
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon May 2 23:15:43 2005