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

Re: Alternatives for remote access?

From: John P N Pybus <john.pybus_at_zoology.oxford.ac.uk>
Date: 2002-08-30 21:47:14 CEST

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. It's
> > 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 it's
> reliability, and lack of suckage vs. CVS. The best way to ensure follow
> through on the marketing tool is by reducing the setup barrier. If we
> 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 model.

I'm already sold on the many advantages of subversion, but until it can
replace the functionality my workgroup are used to from CVS its hard to
justify upgrading. It would be silly to suggest to CVS users whose working
methods rely on 'cvs annotate' that subversion can do everything they need
before svn blame|praise|synonym-de-jour is implemented. It's equally silly
to pretend that a subversion without a remote access method that doesn't
require a network daemon can replace all of CVS's current use cases.

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


John Pybus

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 30 21:47:55 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.