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

Re: Fix to cvs2svn.py -p option for 1.0

From: Ben Reser <ben_at_reser.org>
Date: 2004-01-08 22:09:36 CET

On Thu, Jan 08, 2004 at 12:12:01PM -0600, kfogel@collab.net wrote:
> It would be a terrible mistake to tie the release of Subversion 1.0 to
> the state of cvs2svn. If the rest of Subversion is ready, and cvs2svn
> is not, then we shouldn't wait for cvs2svn. Why should the people who
> want to start using Subversion without legacy data be punished,
> especially since it wouldn't bring Subversion to those who *do* have
> legacy data any sooner? It doesn't make sense.

Well I wouldn't delay 1.0 for cvs2svn. But I wouldn't not include a
cvs2svn.

> We can ship with what we have, include a clear warning that cvs2svn is
> not done, and pointers to where to track its progress. Or, we can
> ship without it entirely. But delaying Subversion's release for an
> essentially arbitrary amount of time would be like saying "We'll camp
> here for the night, oh and by the way construct a nuclear reactor from
> spare parts in the morning, then make for summit in the afternoon."
> Yeah, right.

Oh I don't anyone is advocating that. But you better look out for the
US military when you start constructing that nuclear reactor. They
don't seem to like that very much. :)

Seriously, though I think we should ship cvs2svn, ship the best version
available at the time, and like you said provide documentation that
points to a place to look for updated versions of it.

That makes perfect sense to me.

-- 
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 8 22:10:28 2004

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.