RE: Re: cvs2svn conversion directly to git ready for experimentation

Hello Michael, 
I will explain a scenario (we are passing thru this right now) 
1) you have 10 years worth of cvs data.
2) We want to move to svn. 
3) The repository move should be in such a way that the development does
not get hampered for any 1 work day.   
4) We have atleast 4 major modules in cvs which takes about 30 - 40
hours each for conversion currently.
5) With increamental conversions we can do a few things ... 
	A) Keep the downtime for hard cutoff minimal 
	B) try out the svn move for other auxillary tools that are
needed by the SCM process. 
	C) Do some meaningful testing and validation with simulated live
moves of changes from cvs to svn before the actual move on a day to day
basis. 

Hopefuly this would substantiate the request \ need for increamental moves. Or if someone out there has a better suggestion for such scenario's please point me in the right direction.

Regards, Rajesh

-----Original Message-----
From: Michael Haggerty [mailto:mhagger@alum.mit.edu] 
Sent: Friday, August 03, 2007 1:36 AM
To: Martin Langhoff
Cc: Guilhem Bonnefille; git@vger.kernel.org; users@cvs2svn.tigris.org
Subject: Re: cvs2svn conversion directly to git ready for
experimentation

Martin Langhoff wrote:

I don't see any fundamental reason why not, but I think it would be a significant amount of work. There are two main issues:

1. With CVS, it is possible to change things retroactively, such as
changing which version of a file is included in a tag, or adding a new
file to a tag, or changing whether a file is text vs. binary.  And many
people copy and/or rename files within the CVS repository itself (to get
around CVS's inability to rename a file).  This makes it look like the
file has *always* existed under the new name and *never* existed under
the old name.  An incremental conversion tool would have to look
carefully for such changes and either handle them properly or complain
loudly and abort.

2. cvs2svn uses a lot of repository-wide information to make decisions
about how to group CVSItems into changesets, and a lot of these
decisions are based on heuristics.  Incremental conversion would require
that the decisions made in one cvs2svn run are recorded and treated as
unalterable in subsequent runs.

This hasn't been a priority in the Subversion world, because, frankly, what reason would a person have to stick with CVS instead of switching to Subversion, given that (1) they are intentionally so similar in workflow, an (2) there is no significant competition from other centralized SCMs? But of course until the distributed SCM playing field has been thinned out a bit, people will probably be reluctant to commit to one or the other.

I don't expect to have time to implement incremental conversions in cvs2svn in the near future. (I'd much rather work on output back ends to other distributed SCMs.) But if any volunteers step forward (hint, hint) I would be happy to help them get started and answer their questions. I think that cvs2svn is quite hackable now, so the learning curve is hopefully much less frightening than when I started on the project :-)

Michael

--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@cvs2svn.tigris.org For additional commands, e-mail: users-help@cvs2svn.tigris.org