Travis P wrote:
>
> On Oct 24, 2004, at 2:47 AM, Peter Williams wrote:
>
>> Let me put it this way. For svn to be a REPLACEMENT for cvs it would
>> be sufficient for me to replace "cvs" with "svn" in any scripts that I
>> might have and the would work with subversion just like they did with
>> cvs. This isn't the case.
>>
>> However, SVN is an ALTERNATIVE to CVS for managing revision control.
>
>
> I think you're splitting hairs unproductively here. The language isn't
> that standard and precise. We English speakers world-wide can't even
> all agree on how to spell color or whether the game is tic-tac-toe or
> noughts and crosses.
As long as CVS is singled out in the "SVN is a replacement for"
promotions I think that my expectation (i.e. SVN is CVS with better
implementation and some extensions) is justified.
>
> You did write "for me," and certainly you are welcome to feel as you
> do. You're saying that "replacement" should only refer to a strict
> drop-in identical function CLI client replacement.
Not necessarily identical. A super set would be appropriate so that the
added goodies that SVN provides can be used.
> I don't think the
> authors of the phase "a compelling replacement for CVS" meant
> "replacement" as you seem to wish they did:
I contend that by singling out CVS that's what it MEANS. It may not
have been their intention for it to mean that but intentions are hard to
determine we have to go by the words we read.
> toward the same ultimate
> goal of a free, copy-modify-merge version control system, Subversion
> offers an alternative that you might use in place of CVS (to replace
> your use of CVS). Also, Subversion is more than just the command line
> client. Even if the 'svn' CLI client worked exactly like CVS, someone
> else could present your argument for the server-side.
I doubt it. The user interface is what defines the functionality of a
piece of software for a user. What happens internally doesn't really
matter to them.
>
> Ultimately, I don't think you'll find much traction with your argument.
>
> That said, I suppose someone could make a wrapper over the Subversion
> client-side system so it looks and acts just like CVS -- maybe not
> wrapping the 'svn' client, but using the bindings and exposed API. You
> don't need the existing developers to help you reach that goal. But you
> do need some developers from somewhere, maybe even yourself.
Yes, but in the meantime can you replace the word "replacement" with the
word "alternative" in your promotional material and documentation.
>
> In my development flow, since it is such a compelling alternative :-),
> I've totally replaced our use of CVS with Subversion and we developers
> use the two systems differently, each according to their specific design
> and implementation, for the same ultimate goal for version control. And
> for our needs, Subversion works a whole lot better, so a big thanks to
> all the folks that developed it!
IMHO, with SVN you gain some but, unfortunately, you also lose some when
you switch from CVS. Whether the gains matter more than the losses in
any particular case determines whether it's worth switching. I'm using
both. To me the big gain with SVN is the ability to handle the renaming
of files and directories. To a lesser extent I like the ability to do
atomic commits and the back up an restore mechanism. But in cases where
they aren't important to me I'm sticking with CVS because it has a
better user interface especially when there's lot of branching and
tagging happening.
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 Mon Oct 25 00:44:53 2004