At 09:19 PM 2/9/2002 -0800, Sean Russell wrote:
>I've got two basic systems, with one variation. Each has its advantages.
>I'll outline them briefly.
>
>== Branch controlled reviews
>1) Each developer has their own branch.
>2) When a developer finishes a "task", they commit and make a note of the
>version. The rational/reasoning for the commit goes in the log file.
>3) The other developers are alerted to this commit. This can happen in a
>number of ways, such as a COMMITS file in the main branch, with
>developer/version pairs, or via email. Whatever.
>4) At lesiure, the other developers pull a commit out of the queue and do a
>diff on the main branch vs. that commit, and review the commit.
>5) They yea or nay it, request information, whatever.
>6) When it finally gets enough "yeas", the originaly developer merges that
>commit into the main trunk.
I've been thinking for a while that this system is the right way to go
since it is so easy for everyone to integrate into their own varied systems
once branches become cheap.
I have two points on your design, though. The first is that
branch-per-developer is only one way to do it, and probably not the best
for your situation considering that what you want is broken down into
"tasks". How about branch per changeset? You could name branches after
issue numbers in your bug tracking software, or allow any developer to
freely create any branches they wanted, with the understanding that it
doesn't get into the trunk without approval.
Branching by task rather than developer allows developers to work on
several tasks in isolation, and also allows groups of programmers to work
on the same set of changes in a coordinated way.
>I like this system for a couple of reasons. We can do it now (well, as soon
>as merging works), it is pretty straightforward, and there's no added
>infrastructure. The downsides? Well, mainly that it relies fairly heavily
>on people, and there are a lot of points of failure.
Actually, you can automate as much or as little as you like, so long as you
use a framework outside of the core svn client (where it would be far too
specific).
Consider a script that wraps the svn client, for example, with a user
interface like this:
% cs-svn help
Changeset-SVN usage: cs-svn command options
where command is one of:
create - new copy of trunk in "/changesets/[newname]" where newname can
be defined on command line or taken from a property kept on the
changesets directory, incremented by one
update - Merge changes from trunk onto branch, then update working copy
submit - Add svn:submit property to the "/changesets/[newname]" directory
list - List subdirectories of "/changesets" which have the "svn:submit"
property
agree - Add your email address to the "svn:agreelist" property on the
"/changesets/[newname]" directory
disagree - Add your email address to the "svn:disagreelist" property on the
"/changesets/[newname]" directory
approve - Merge the branch back to trunk, remove the "svn:submit"
property, and move the branch to an "/approved" directory.
But a server-side script only allows this if the svn:agreelist
and svn:disagreelist match with the local rules governing such
things.
cancel - Remove the "svn:submit" property, and move the branch to a
"/cancelled" directory.
Well, you get the idea. Properties should probably not be in the svn
namespace, and it might work better with some sort of "state" property for
the branch, but I think the basic premise is sound. So long as people used
the cs-svn script (or whatever) consistently rather than trying to do it
all manually, I think that most of the problems you foresee above disappear.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:06 2006