Jeremy Pereira wrote:
>
> 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.
I note that you understand that tags and branches are different but you
still seem to think that they are IMPLEMENTATIONS of one thing.
>
> 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.
But it has to be a deliberate act. You can't accidentally move a tag in
CVS or accidentally modify the tagged items. This is NOT true of SVN
copies. The the movement of a CVS tag isn't recorded is certainly a
deficiency of CVS but it's one that can be fixed when SVN does tags
properly.
> 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.
I admit that CVS has deficiencies and that's why I'm looking for a
replacement. But, my point is, SVN isn't a replacement for CVS it's a
different tool that is intended for the same purpose as CVS.
I got all excited when I heard about SVN as it was touted as CVS with
improvements and extensions. But it's not that it's something else and
that's the cause of my disappointment.
>>
>>> 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".
More "not having to keep to much data in my head" and then as a result
of it being in my head instead of in the repository having to type it.
>
> 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.
This is (almost) an example of the kind of improvement that the SVN
interface needs except that svn should look for the environment variable
automatically. At the moment SVN forces users to do things by hand
(over and over again) that should be automated with the help of some
configuration files and/or environment variables.
>
>>
>>> 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",
This statement is wrong at two levels; 1) fundamental and 2) convenience.
At the fundamental level I will grant that branches are just copies but
I will not grant that tags are just copies. Tags are immutable copies.
There is a difference.
At a convenience level, both tags and branches are labelled and SVN
copies are not. Instead of just having to remember the label you have
to remember the full path to their whereabouts in the repository.
> 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).
But requires the use of a series of more complicated commands to achieve
the same end.
>>
>>
>> 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 Sun Oct 24 00:44:08 2004