Thank you very much for the email. Yes if the time for conversion can be brought down to 1/2 hour then it would be really great. We could do a automated cvs2svn everyday for testing and that way maximum lag between cvs and test svn repo would be 1 day. Please do let me know when available. Regards, Rajesh -----Original Message----- From: Jon Smirl [mailto:jonsmirl@xxxxxxxxx] Sent: Friday, August 03, 2007 8:41 AM To: Patwardhan, Rajesh Cc: Michael Haggerty; Martin Langhoff; Guilhem Bonnefille; git@xxxxxxxxxxxxxxx; users@xxxxxxxxxxxxxxxxxx Subject: Re: Re: cvs2svn conversion directly to git ready for experimentation On 8/3/07, Patwardhan, Rajesh <rajesh.patwardhan@xxxxxxxxxx> wrote: > > 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. There are known ways (that haven't been implemented) to get the 40 hr number down to 1/2 hour. Would that be a better approach than doing incremental imports? > 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@xxxxxxxxxxxx] > Sent: Friday, August 03, 2007 1:36 AM > To: Martin Langhoff > Cc: Guilhem Bonnefille; git@xxxxxxxxxxxxxxx; users@xxxxxxxxxxxxxxxxxx > Subject: Re: cvs2svn conversion directly to git ready for > experimentation > > Martin Langhoff wrote: > > Is there any way we can run tweak cvs2svn to run incrementals, even > > if > > > not as fast as cvsps/git-cvsimport? The "do it remotely" part can be > > worked around in most cases. > > 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@xxxxxxxxxxxxxxxxxx > For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxxxx > > - > To unsubscribe from this list: send the line "unsubscribe git" in the > body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at > http://vger.kernel.org/majordomo-info.html > -- Jon Smirl jonsmirl@xxxxxxxxx - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html