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

Comparing notes on branch-per-task methodology

From: Campbell, Matthew A <Matthew.Campbell_at_Relizon.com>
Date: 2004-07-30 18:07:38 CEST

We're adopting a branch-for-every-task methodology here at the office and I know
there's some others on this list who work in a similar setup. Now that I'm
feeling really comforable with my unserstanding of the underlying SVN
technology, I was hoping to compare notes with regards to a few points on the
actual day-to-day *use* of the thing, in this particular model.

1) Do you use the trunk/ == production (stable) model? This is the way we're
working it and it seems to me to be a good idea, but I also realize that it's
not-quite-totally the conceptual inverse of the Subversion team's own model
(which is also, I believe, a classic open-source repopsitory model as well).
Are there any pitfalls to this approach? (Conceptual, implementational,
habitual, or otherwise?)

2) When a task on a branch is completed, do you always attempt a merge with the
trunk, or do you compare revision numbers first? Our idea here is to compare
the current revision number of the trunk with the revision number from which the
branch was created (stored in a property). If ( current_trunk_rev >
branch_start_rev ) we flag the merge case and attempt a merge from trunk, revs
branch_start_rev:current_trunk_rev into the branch. If not, then we "svn rm"
the trunk and "svn cp" the branch back "on top of" the trunk.

3) Addendum to the last point... after a branch/task goes back to production
(trunk), do you delete the branch? There's really no reason to keep it there -
it's not like the data goes away anyway - and the old branches would now just be
excess clutter. Plus, as long as the commit logs on the trunk are thorough -
like "moving branch for fooapp, task 1234 into production" - you can always drop
to (commit_log_revision - 1) in branches/ and the branch for fooapp_1234/ should
be right there.

Thanks in advance for all replies...

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jul 30 18:10:43 2004

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

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