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

Re: A failed attempt to introduce Subversion

From: <kfogel_at_collab.net>
Date: 2004-03-22 18:05:13 CET

"Alexander L. Belikoff" <abel@vallinor4.com> writes:
> I understand. The issue here is that it is usually the first
> acitvity new SVN users are subjected to. I went over the book
> several times in the past - is there another way to import changes
> (obviously, other than doing manual checkin for each revision)?
> Making it work is fairly important to prevent the "version 1
> syndrom" where people try version 1, immediately find a showstopper,
> say "It sucks", and never try this program again. ;-)

By the way, what version of cvs2svn were you using? The one from the
Subversion 1.0.0 tarball, or the very latest from cvs2svn.tigris.org?
If you weren't using the latest, try again; cvs2svn is improving at a
very rapid rate.

> As for the requirements to transfer the revision history, well it
> seems to be so natural for me that there is no reason to even list
> it. In fact I doubt
> any serious company would consider a tool that cannot import the the history
> of the product, especially if this company is under SEC requirements and
> such :-) After all we are not talking about some proprietary system like DEC
> CMS importing from which could be a major pain. We are talking about most
> open and widely documented format - RCS.
> [...]
> You are wrong here. cvs2svn *is* part of SVN :-))))) It is
> perceived as such by most of people I've dealt with. Otherwise, we
> are left with SVN as a tool unable to migrate an existing repository
> into itself. If I proposed migrating to SVN without being able to
> import the entire repository, the tool would've been rejected before
> I had managed to finish the sentence.

Heh. Nope :-).

It's like saying that Win32 executable compatibility is part of the
Linux kernel's "requirements" simply because many new users expect to
be able to run Windows programs under Linux. The WINE project came
along and solved it, but if they hadn't, would you blame Linus and
friends for not supplying it?

In general, you wouldn't expect *every* revision control system to be
able to convert history from every other system, would you? Sure, you
might expect that Subversion would convert CVS history, because SVN is
designed specifically to replace CVS. But we don't consider that
conversion a feature of Subversion, by the following logic: anyone
starting a new project would *never* need that feature.

Many people start projects from scratch, instead of migrating existing
data. So Subversion is *quite* useful without a finished converter.

Another way to look at it is: why not expect the CVS project to supply
the converter, instead of SVN? Subversion has existed for the same
amount of time for both projects, after all. Of course, you don't
expect to find the converter at cvshome.org, but analyzing *why* you
don't expect that might be interesting...


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 22 19:15:03 2004

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