On Oct 23, 2004, at 06:57, Peter Williams wrote:
> 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.
Good. That's one more thing I don't have to remember.
You're looking at the whole problem the wrong way around. Tags and
branch tags in CVS are it's way of implementing a copy command. What
is a branch? It's a copy of a module that you can do development on
without disturbing the main line. What is a tag? It's a copy of a
module at a particular point in its life cycle.
Seen this way, the appalling hack that is CVS tags becomes obvious. It
even has a deficiency in comparison with subversion's copy command -
creation of tags and branches and modifications to them are not
versioned. If I decide to move a tag in CVS, nowhere is it recorded
why I did it, when I did it or even that it was me that did it. BTW if
I move the "rel-1-0" tag for foo.c what I am really doing is making a
new version of the release with a different foo.c. It seems
fundamental to me that this should be recorded in what purports to be a
version control system.
>
>> 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.
I see, "user friendly" is the same as "not having to type too much".
One day I'll put an environment variable in my profile that I can use
to refer to my repository URL.
svn diff $REPO/proj/trunk $REPO/proj/releases/1.0
doesn't seem too unfriendly to me.
>
>> 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
>
>
>
--
Jeremy Pereira
http://www.jeremyp.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Oct 23 11:25:14 2004