Monks, Peter wrote:
> G'day again,
>
>
>>No you wouldn't. It would be perfectly acceptable for a CVS
>>replacement to provide extensions to CVS's functionality. But a
>>CVS replacement has to include all of CVS's current features and
>>SVN doesn't do this. It has features which could be used to
>>implement the missing CVS features.
>> The most useful CVS features that fall into this category
>>are tags and branches.
>
>
> ?? Subversion does implement tags and branches, albeit via a
> different mechanism than CVS (ie. "zero cost copies"). This is
> discussed in some detail in the SVN book (http://svnbook.red-bean.com/)
> and has been discussed ad nauseam on this list.
No it does not. It provides a mechanism to do something similar to what
tags and branches do.
>
> And yes I have read many of the posts that argue that Subversion
> copies aren't "real" tags or branches "because they're not implemented
> the same way as CVS / VSS / insert-your-favourite-SCM-tool-here does
> it". IMVHO these arguments completely miss the point: Subversion
> supports the exact same use cases that CVS / VSS / what-have-you
> support, just in a different way.
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.
>
> Now I'd agree that there are some small tweaks that would improve
> Subversion's copy functionality (eg. immutable copies perhaps),
> however to my mind these are all minor quibbles - Subversion's basic
> abstraction of tags and branches as copies is a fundamentally sound
> model.
Maybe but that's a different point to what I'm trying to make. 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.
>
>
>>If you don't think this matters compare the usefulness of the
>>CVS based team interface in Eclipse with the SVN based team
>>interface (subclipse) in Eclipse.
>
>
> I completely agree that some of the add-on tools for Subversion don't
> yet match up to some of the add-on tools for CVS. But:
>
> 1. the maturity (or lack thereof) of add-on tools for Subversion
> doesn't have anything to do with the maturity (or lack thereof) of
> the core Subversion software, nor with the integrity of
> Subversion's basic design
Here I disagree. SVN needs to sacrifice some flexibility in order to
improve its usability.
>
> 2. I have faith that the add-on market for Subversion will grow and
> mature at a far faster rate than it ever did with CVS (although I
> was only an active CVS user for about 5 years, so perhaps the add-on
> market for CVS was more dynamic prior to my exposure to it)
And a (more) user friendly command line interface for branching and
tagging will probably be one of those. :-)
>
>
>>The difference is most visible when you wish to do something like
>>compare a working copy with an arbitrary branch or version. This is
>>easy for the CVS based version but unavailable in the SVN based one
>>probably because it's got no easy way of finding the other branch in
>>the repository (it requires knowledge only available in the person
>>who planned the repository's head and that's difficult to extract
>>programmatically).
>
>
> True. And there are other functions (such as reserved checkouts) that
> Subversion is missing too, however none of these are incompatible with
> Subversion's current design, and hence can't be used as proof that
> that design is fundamentally flawed in some way.
>
>
>>So while SVN may be useful and have the same general purpose as CVS,
>>it is NOT a replacement for CVS and shouldn't be advertised as such.
>
>
> I guess we'll have to agree to disagree then.
>
> I've used CVS quite extensively for a reasonable amount of time, and I
> can't think of a single thing that I've lost by switching to
> Subversion. Add to that the fact that many of the most annoying
> limitations of CVS are gone and I'm comfortable in describing
> Subversion as a "compelling replacement for CVS".
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.
>
>
>>It does, however, have useful features that CVS lacks but on the
>>other hand it lacks some useful features that CVS has (i.e. a user
>>friendly tag/branch interface).
>
>
> Unless CVS has changed greatly in the last 6 months, it doesn't
> include a user friendly tag/branch interface either - that's provided
> by add-on tools (such as the Eclipse CVS UI you mentioned earlier).
The command line tag/branch interface of CVS is much more user friendly
than the SVN copy mechanism.
To me SVN as it is now compared to what it should be is similar to what
RCS is/was to CVS. I.e. it's got the necessary basic mechanisms and
just needs a more user friendly user interface. NB by more user
friendly interfaces I don't mean GUIs although they are welcome additions.
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 03:26:11 2004