Monks, Peter wrote:
> 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 about the user interface. SVN does NOT have a branch or tag user
interface it has a copy interface. A branch/tag interface COULD be
implemented using the copy interface but that is not the same as having
a branch/tag interface.
>
>
>>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?" ;-)
There is no "svn tag" command. It's that simple.
>
> 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)! ;-)
But it's at a primitive level. You have to REMEMBER where abouts in the
repository YOU PUT these branches and tags. In other words these things
are only branches and tags in YOUR MIND. They aren't really branches or
tags. They're copies :-)
>
>
>>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.
OK. I'm aware that some flexibility would be lost. But my point is
that with flexibility comes complexity (always) and complexity is bad
for usability (usually).
> 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?
It would be a matter of coming up with a convention/mechanism that
supported branching and tagging at any level. This may involve another
database to remember where various tags and branches are stored.
BTW CVS allows tagging and branching with arbitrary granularity. Not
that I'm a great fan of tagging/branching at other than the module level
with CVS.
>
>
>>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?
Yes. 1) it's a lot of typing, and 2) I have to REMEMBER what to type
in. And the real unfriendly bit comes when you want to do diffs.
>
> 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! ;-)
It should be an "under the covers 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).
SVN is (potentially) more useful than CVS but its user interface could
be better.
To summarize my disappointment: SVN's advertising (as I interpreted it)
promised me CVS with some long overdue enhancements but that's not what
it delivered. It's got the long overdue enhancements but is missing a
user friendly interface for tagging and branching. Whether I'll learn
to live with that is currently being determined ;-)
It will probably depend on whether I can find the time and energy to
write myself some wrapper scripts before I find an alternative tool.
Peter
--
Dr Peter Williams, Chief Scientist peterw@aurema.com
Aurema Pty Limited Tel:+61 2 9698 2322
PO Box 305, Strawberry Hills NSW 2012, Australia Fax:+61 2 9699 9174
79 Myrtle Street, Chippendale NSW 2008, Australia http://www.aurema.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Oct 23 07:58:14 2004