G'day,
> No it does not. It provides a mechanism to do something similar to
> what tags and branches do.
Would you mind explaining in detail the use cases that CVS handles
that SVN doesn't? I still don't understand what it is you think CVS
tags / branches can do that SVN copies can't.
> It's nothing to do with how their implemented because they aren't.
> The SVN copy mechanism is a mechanism that COULD be used to
> implement tags and branches but SVN chooses not to do that.
To quote an (in)famous Australian: "please explain?" ;-)
Using the copy command I create tags and branches in my SVN
repositories all the time, and they behave exactly as I expect tags
and branches to behave. I can commit against the trunk, I can commit
against a branch, I can merge changes between branches or back into
the trunk, I can switch my working area between two branches, or
between a branch and the trunk etc. etc. etc. etc. ad infinitum.
It all works beautifully (well there are some things that could be
fine tuned, but by and large it works very well)! ;-)
> What's really needed is a nice user friendly tag/branch interface as
> a wrapper around the copy function. This would probably entail
> enforcing a standardized folder layout within a repository so that
> the wrapper knows where to find tags and branches but this SMALL
> loss in flexibility would be more than compensated for by the
> improvement in usability.
What you propose would be an unacceptable loss in flexibility in my
situation. I am currently (jointly) responsible for two independent
repositories, both of which used to be hosted in CVS and both of which
are now hosted in SVN. Each repository has a different layout,
specifically because we need differing levels of granularity for
tags and branches in each of the two repositories (which was a major
hassle while we were still using CVS).
One of them is your typical bespoke application where tags and
branches apply to the entire codebase. The other is a set of code
modules (libraries, programs etc.) for a number of independent
products where we tag or branch code at the product level (ie. tagging
or branching the entire codebase makes no sense).
How would SVN support both of these requirements if the granularity of
tagging and branching was fixed and no longer under my control as a
repository administrator?
> Here I disagree. SVN needs to sacrifice some flexibility in order
> to improve its usability.
I disagree. IMVHO hard-coding policy decisions (such as this one) is
almost always a bad idea - inevitably a use case appears that violates
your well intended (but hardcoded) policy, and at that point you're
hosed.
> And a (more) user friendly command line interface for branching and
> tagging will probably be one of those. :-)
It might be "user friendly" to some, but it would make SVN less useful
for those of us who have requirements that can't be satisfied by a
standardised repository layout.
> By singling out CVS in this way there is an implication (or, at
> least, I (and I suspect may others) infer) that SVN has the same
> feature set as CVS plus extensions and improvements which isn't
> true. It does have the extensions and improvements but it doesn't
> have the same feature set.
I think we have to agree to disagree on this point. In my (limited)
experience with SVN, there is nothing that I could do with CVS that I
can't also do with SVN.
> The command line tag/branch interface of CVS is much more user
> friendly than the SVN copy mechanism.
Let me ask a question. Do you, as a SVN user, find either:
svn cp svn://host/repos/trunk svn://host/repos/tags/mytag
or
svn cp svn://host/repos/trunk svn://host/repos/branches/mybranch
unfriendly?
Granted it's a conceptual leap for someone who is used to some other
SCM tool (be it CVS, VSS or whatever) to start thinking of tags and
branches as "just copies", but I think you'd agree that that's not
a software problem, but rather a "wetware" problem! ;-)
In fact I could argue that SVN is MORE user friendly than CVS, since
it dispenses with a bunch of redundant commands (ie. the tagging and
branching commands).
Cheers,
Peter
----------------------------------------------------------------------
Peter Monks http://www.sydneyclimbing.com/
pmonks_at_sydneyclimbing.com http://www.geocities.com/yosemite/4455/
----------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Oct 23 06:59:42 2004