Matthew Campbell wrote:
>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.
>
>
I don't actually use this model, at least not lately (and not with
Subversion), but I do have a few comments (and I'll try to avoid
speaking my mind about the branch-per-task pattern itself. :-)
>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?)
>
>
I think this is quite conformant to the branch-per-task pattern. The
fact that the Subversion project uses (and recommends) a different
pattern does not mean that SVN is in any way optimised for it. The only
potential drawback of branch-per-task with Subversion that I can see is
a consequence of an ommission in SVN, namely, that we don't store merge
history. This causes a bit more administrative overhead for tracking the
merges, which I see you've noticed. (And will be fixed in the future.)
>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.
>
>
This removing of trunk strikes me as wrong from a conceptual point of
view. You're effectively branching your stable branch off your task
branch, which is exactly the opposite of what branch-per-task is all
about. If Subversion did merge bookkeeping, this would complicate it
quite a bit. :-)
In practical terms, I don't think you gain anything by doing that (you
don't save any space in the repository, for example), and your merge
process (and bookkeeping!) become more complicated.
>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.
>
>
Exactly. I'd recommend removing obsolete branches myself. There's not a
single reason for keeping them around, and you can always resurrect them
if necessary.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 31 13:57:23 2004