On 7/5/07, C. Michael Pilato <cmpilato@collab.net> wrote:
> 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
>
>
These two complaints are very real, and very serious.
I recently led a CVS to SVN migration a repository at work, and
for many developers it was not a positive experience, mostly due to
how branches and tags are (not) handled by SVN. A number of
developers remain unhappy with it after several months. All these
developers 'get' branching and tagging in CVS and SVN, and most
previously used branching in CVS. Our primary reason for moving
to SVN was better branching (CVS is basically unusable) and directory
tracking. Some of us are realizing those benefits, but many
developers just see the regressions.
Some of the big problems are:
* Subversion makes some very useful operations much more difficult than CVS:
- for a given file, provide a list of tags and their corresponding
revisions. (We are interested in where the file changed, so the
repository revision created by the tag is not interesting. If 10 tags
where made from the same version of the file on trunk, they should
have the same revision.) SVN would also need to provide paths for the
revisions due to tags/branches being in the normal filesystem
namespace.)
- for a given file, draw a graph that shows branches and tags.
TKCVS does this very nicely and instantaneously for CVS. TKSVN sort
of does this, but the implementation is a hack, and it only works on
repositories with 'clean' history. Even when it works it is orders of
magnitude slower. (Someone accidentally removed the entire 'tags'
directory from the repository. Doing the simple fix of just copying
it from a previous revision completely broke TKSVN due to log
--stop-on-copy now giving the revision where the copy of the tags
directory was done. We had to do a dump/load to fix TKSVN.) Drawing
these graphs in a robust manner requires processing the complete
history of the repository - even if a program implemented this, it
would be very slow.
The branch/tag handling in SVN is a nice implementation, but it is
lacking in its
handling of the difference in meaning between
directories/tags/branches. This is all left to convention, and other
tools, which means that there is no consistent way of doing things.
These problems seem to have been defined as 'someone else's problem',
so they remain outside the scope of things that should be fixed in
subversion. In this aspect SVN is much more a versioned file system
rather than a version control system. For instance, 'log
--stop-on-copy' is used as a proxy to determine when a branch/tag was
created, but this is not always right (see above about tags dir
deletion.)
I hope that as Subversion continues to mature that these issues will
be addressed.
I think that many users expect a version control system to care about
the concepts of branches and tags, even if the underlying
implementation doesn't care.
Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 6 19:55:51 2007