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

RE: Comparing notes on branch-per-task methodology

From: Campbell, Matthew A <Matthew.Campbell_at_Relizon.com>
Date: 2004-08-02 15:23:44 CEST

> 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.
>

Funny. The entire reason I wanted to do it this way is the total lack of
merge bookkeeping in Subversion, primarily the inability to do a one-step
"svn blame" to find the author of a bug.

I'm beginning to see the merits of not doing it this way however - not the
least of which is that once svn does have proper merge accounting (which I
don't expect prior to 2.0 since I think it requires a repos schema change),
this procedure would need to be changed, which means needing to "un-train"
people. (And let me tell you, wetware is a real pain to de-program.)
Additionally, trying to eliminate the need to do the extra bookkeeping to
track down bug ownership "as much as possible" is pointless when an
inevitable real merge case comes along. Best to train the user base how to
do it the "worst-case" way now and make *that* the standard.

Thanks for the feedback, everyone, the discussion has really helped put
things in good perspective for me!

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Aug 2 15:57:04 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.