Comparing notes on branch-per-task methodology

[Campbell, Matthew A <Ma...@Relizon.com>]

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

Re: Comparing notes on branch-per-task methodology

[Branko Čibej <br...@xbc.nu>]

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