Graham Leggett wrote:
> On Wed, July 4, 2007 2:37 pm, Branko ÄŒibej wrote:
>
>> Why? I'm really interested: What, exactly, do you (we) gain by that?
>
> The concept returns to the original method of version control that people
> used before there was version control, and that was to "make a copy of a
> the source directory". Tags modelled like directories are easy for new
> users to understand.
>
>> Compared to all the real pain it's causing.
>
> Having introduced this concept during a number of migrations to
> subversion, I honestly haven't seen anyone go through any pain.
Yeah, I have to say that in my experience, Subversion's approach to
branching and tagging has only ever been a benefit to them in terms of
reducing a complex concept to a comprehensible one.
I do see seasoned version control users get tripped up, but it's typically
in slinging the specific command lines needed for merges, not in the
"concept comprehension" department.
There are only two realistic complaints that I can recall seeing leveraged
against Subversion's way of doing branches and tags:
1. all that flexibility makes it harder for Subversion and other third-party
tools to recognize and treat a directory copy as a branch. Common questions
like, "What tags exist?" can't be answered unless the answering system first
understands the policy used to denote tags in a given repository ("stuff
immediately under /tags"; "stuff immediately under an immediate subdirectory
of /tags"; ...)
2. in a multi-project-under-single-trunk repository, whether a tag/branch is
created as a copy of a particular project's directory or of the whole trunk
is a matter of policy, and if not consistent, can really screw up people's
attempts to switch a working copy to such a branch.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Thu Jul 5 14:18:01 2007