[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Re: Alternatives for remote access?

From: Bill Tutt <rassilon_at_lyra.org>
Date: 2002-08-30 22:07:24 CEST

> From: John P N Pybus [mailto:john.pybus@zoology.oxford.ac.uk]
> On Friday 30 Aug 2002 7:03 pm, Bill Tutt wrote:
> >
> > > If ra_pipe were out there, we could lure in hundreds of users, and
> > > then gradually convince them to upgrade to apache and ra_dav.
> > > the best marketing tool there is. I'm thrilled that people are
> > > working on it.
> >
> > The best marketing tool is word of mouth praising Subversion for
> > reliability, and lack of suckage vs. CVS. The best way to ensure
> > through on the marketing tool is by reducing the setup barrier. If
> > don't have enough positive features to overcome any of the issues
> > related to not having ra_pipe, then in my view we've failed to add
> > enough features to make Subversion compelling enough to consider
> > overcoming whatever issues there are at not having a ra_pipe like
> I'm already sold on the many advantages of subversion, but until it
> replace the functionality my workgroup are used to from CVS its hard
> justify upgrading. It would be silly to suggest to CVS users whose
> working
> methods rely on 'cvs annotate' that subversion can do everything they
> before svn blame|praise|synonym-de-jour is implemented.

Actually, it wouldn't be completely silly to suggest that. 'cvs
annotate' output is very handy looking, but how often apart from using
ViewCVS do you actually need to extract the guilty party apart from
looking at previous versions of the code? From what folks have said, it
didn't seem like very often. I know I get along just fine at work having
to deal with the hell that is VSS.

> It's equally silly
> to pretend that a subversion without a remote access method that
> require a network daemon can replace all of CVS's current use cases.

I don't want to replace all of CVS's use cases. I think that would be
dragging too much of CVS's baggage along for the ride.

> The original aim of sunversion was to replace CVS's functionality as
> as
> fix its faults and add new capabilities. That's a lot to bite off and
> won't cover the whole distance by 1.0. This is going to be one of
> gaps. Hopefully it can be filled with future development.

I don't think Subversion will completely ever be a superset of CVS's
entire use case out of the box. I think that's very unrealistic. CVS has
several very broken ideas about how it should do certain things. Group,
and other permission setting as the classic recent example of a hotly
debated issue.

95% intersection with CVS use cases, perhaps, but I don't think we'd
ever want to do a 100% use case intersection with CVS. It's not worth
the extra grief, code management issues, and just plain bad design.

In fact, thinking that Subversion is supposed to be a complete superset
of CVS seems to be a very common misconception. :(


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 30 22:07:56 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.