On Tue, Mar 23, 2004 at 12:34:42AM +0200, Nuutti Kotivuori wrote:
> And as for the associated storage or sandbox - in Subversion it is
> trivial to change the branch that a sandbox is associated to, while
> keeping local edits (unfinished changes) in the sandbox. You can even
> create a new branch from the changes (and versions) that exist right
> now in your sandbox. So there is no need to take sandboxes into
> account at all when deciding whether to re-use the same branch-tag or
> to come up with a new.
Yes - for SVN the above sounds correct when deciding which of
the two patterns to prefer (Private Branch versus Task Branch)
> > The reason for doing that instead of a new-branch per task would be
> > if I could still get the benefits of task-based change-set grouping
> > without having to create so many additional branch-names and
> > associated "copies". If I could reuse the "copy", and let the "name"
> > be associated with revision resulting from porting the changes to
> > the trunk, then I'm still creating new names (that get associated
> > with trunk revisions) but I'm not creating new branches/tags nor
> > their associated copies, and the version tree has a much simpler
> > structure, and I'm still doing a whole lot less copying (even tho it
> > is a lightweight operation, its still not as lightweight as not
> > doing it at all)
>
> Well, yes, by re-using the branches the version tree has a much
> simpler structure in that not so much branching and tagging is going
> on. But on the other hand the logical structure of the version tree is
> more complex, since a single branch has several successive tasks, with
> lulls in between possibly, instead of just having small branches with
> short lifetimes that get merged back to trunk, having only one task
> per branch.
Here I'm thinking The one with fewer branches (and more
"change-sets" on a branch) is the less complex. Think of
a UML sequence diagram. Let's say each "branch" gets its
own "object lifecycle" instance and "swim-lane" and
each change task/activity get's its own little "box" of
activity on the lifeline of the branch the activity takes
place upon. The result might look very similar to
http://acme.bradapp.net/branching/#VTreeDiagrams
(only top-to-bottom instead of left-to-right :-)
Here, "featureA" and "featureB" are examples of "activities"
that take place on the same branch instead of a separate branch.
So I'm thinking if I create fewer branches but with multiple
sequential activities on development branches, I have a
single branch and multiple activities per "lane" instead of
multiple branches+activities per swim-lane. Instead of having
a branch+tag per activity per developer, I have a branch per
developer with multiple activities and tags on it.
SVN doesn't care because branches and tags are both copies.
But the vtree is conceptually cleaner because instead of lots
of disconnected sequential but separate "segments" it has a
single line with a single name/identity and the same number of
"tagged" reference points for each activity.
> Also, you seem to be assuming that copying would be a more
> heavyweight operation than, say, changing a line in a file - other
> version control systems avoid copying by doing other changes, such as
> recording branch-tags somewhere, or merge history - so you cannot say
> that copying costs anything, since the alternative cannot be not doing
> anything at all.
>
> So it seems to me to be avoiding some cost that just isn't there.
With SVN that may be true. With other systems where branches and
tags are separate things with separate mechanisms, the story
would be different. Even with SVN, the cost is still there,
its just that it doesn't changes based on whether you do a
branch or a tag because the same mechanism is used for both.
> > Plus there is a different between being lightweight, and being
> > "perceived" as lightweight. For some folks, no matter how well you
> > explain to them that branching in SVN is inexpensive+lightweight, it
> > still seems conceptually "heavyweight" to them. And even if the
> > implementation of doing so is lightweight, it will still seem
> > conceptually more complex (as will having to delete+rebranch,
> > something they would regard as an indication of additionally
> > technical "residue" required by the additional conceptual
> > complexity, for something they see as not being necessary in the
> > first place).
>
> Well yeah, a lot of people have emotional baggage left over from
> previous version control systems that can be hard to deal with.
Emotional baggage and conceptual baggage are different things.
Just as a domain/analysis model can have differences from a
design/implementation model - the differences between the two
aren't necessarily emotional, and do correspond to important
user needs. I have learned the hard way that it is unwise
to casually dismiss such a difference as emotional, and that
whenever there is a difference between the conceptual "domain"
model and the design/implementation model, that ignoring or
dismissing the difference as unimportant usually will come
back to bite me in the end.
So while I agree it is different, I would urge you to please
not be so quick dismiss the difference as emotional/unimportant
just because the technical cost may be the same. Those conceptual
mismatches usually have something important to tell us about a
fundamental need that would do us well to better understand.
--
Brad Appleton <brad@bradapp.net> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 23 01:34:56 2004