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
