You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Alexander L. Belikoff" <ab...@vallinor4.com> on 2004/01/27 06:51:25 UTC

Re: not SVN?

On Monday 26 January 2004 07:41, Florian La Roche wrote:
> On Mon, Jan 26, 2004 at 07:07:56AM -0500, Alexander L. Belikoff wrote:
> > On Sunday 25 January 2004 00:28, Cristian Gafton wrote:
> > > - Installation of a CVS server and associated repositories as the
> > > primary interface for the developers.
> >
> > Hmm... I thought RedHat was going the way of early adoption of SVN?..
> > *This* could be the perfect moment to start eating our own dogfood. ;-)
>
> I have tried out svn and like it a lot. It is still pretty slow for me
> and the benefits to have branches in "real trees" is not really a
> big improvement.
> You need good support for -HEAD development and everything else should
> be just a few important bug-fixes and security fixes. cvs does fine
> for that.

I understand, but maybe we could still give Subversion a try?.. This would 
have the following advantages:

- We would be eating our own dogfood. I am confident this is a vital part of 
the product success. SVN is provided within the product, so using it for 
"real" stuff would display our confidence in the product.

- It would help Subversion as a product. Not a primary goal, obviously, but a 
good one.

- I am sure the Subversion developers will be more than thrilled to help such 
a high-profile showcase of their software. Based on my experience, they've 
always been very helpful so we should not assume it is going to be different 
in this case. 

- someone has to make the step and bite the bullet. Subversion needs exactly 
this last step that would move it into the spotlight as a legitimate 
successor of CVS. Redhat historically has been very brave in biting the 
bullet (glibc, kernel, XFree86, etc) which helped making it a popular and 
stable platform. This should be easier than glibc ;-)

- It would be much easier to try using it now than to switch later when the 
process has been established and some migration path is required.

So let me ask again - could we give it a try? If it doesn't work (and the SVN 
team cannot help us) - no problem, we'll go back to CVS. Obviously, by 
proposing this, I volunteer to help with setup, configuration, and the basic 
SCM process in case my help is needed.

Cheers,

-- 
Alexander L. Belikoff                      GPG f/pr: 0D58 A804 1AB1 4CD8 8DA9
Bloomberg L.P.                                       424B A86E CD0D 8424 2701
abel *at* vallinor4 *dot* com             (http://pgp5.ai.mit.edu for the key)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: not SVN?

Posted by Ben Collins-Sussman <su...@collab.net>.
On Tue, 2004-01-27 at 00:51, Alexander L. Belikoff wrote:

> - someone has to make the step and bite the bullet. Subversion needs exactly 
> this last step that would move it into the spotlight as a legitimate 
> successor of CVS. Redhat historically has been very brave in biting the 
> bullet (glibc, kernel, XFree86, etc) which helped making it a popular and 
> stable platform. This should be easier than glibc ;-)

Subversion is targeting a 1.0 release date on Feb 23rd.  For many
people, that's going to be the magic number for "trying Subversion" for
the first time.  

My recommendation is not to jump into the deep end and "bite the
bullet", but rather dip your toe in the water at first.  Set up a pilot
program -- convert one smallish project over to Subversion, and see how
people like it.  If it goes well, you can scale up from there.

-Ben, a Subversion developer.




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org