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

["Jon Smirl" <jonsmirl@gmail.com>]

On 8/3/07, Patwardhan, Rajesh <rajesh.patwardhan@etrade.com> 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@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:
> > 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@cvs2svn.tigris.org
> For additional commands, e-mail: users-help@cvs2svn.tigris.org
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Jon Smirl
jonsmirl@gmail.com