Brad Appleton wrote:
> Here I'm thinking The one with fewer branches (and more
> "change-sets" on a branch) is the less complex.
[...]
> 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.
Well, I guess we view complexity in a different way. For me, something
like this is less complex:
http://www.cmcrossroads.com/bradapp/acme/branching/branch-creation.html#BranchPerTask
than something where things from a single branch get merged several
times, like in the example figure you posted.
However, I do see your point - there will be lots of disconnected
segments and a lot of branch operations in the tree, instead of just
having one branch and a lot of merges from that branch.
>> 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.
Oh, definitely. I was talking purely in a Subversion perspective here
- eg. what's best practise for Subversion.
> 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.
Well, the cost is the same as any versioned change to the repository.
>>> Plus there is a different between being lightweight, and being
>>> "perceived" as lightweight.
[...]
>> 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.
Oh sorry - I certainly didn't mean to dismiss it as
emotional/unimportant. I actually meant a different thing.
What I meant that somebody who has never used a version control system
in his life reads the Subversion book as first introduction. That
person will first understand that Subversion can do cheap copies and
after that he will understand that cheap copies can be used for
branching and tagging, for example. To such a person, branching and
tagging *is* perceived lightweight and to be nothing special - since
it is no different than him trying to version his project by taking
copies of it, it just takes less space and is faster.
So such a person does not have the emotional baggage left over from
other version control systems, or the conceptual baggage from reading
branching and tagging operations as somehow special.
Obviously when dealing with humans, such things must be accounted for.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 23 15:58:08 2004