git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
PRPatwardhan, Rajesh <rajesh.patwardhan@etrade.com>
Date
Aug 3, 2007, 16:42 UTC
Message-ID
<0BB549C6E74E24409FB20B3B1D1B664402946577@ATL1EX11.corp.etradegrp.com>
In-Reply-To
<9e4733910708030841r31175efg4ea4ea41e852ab2@mail.gmail.com>

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@gmail.com] 
Sent: Friday, August 03, 2007 8:41 AM
To: Patwardhan, Rajesh
Cc: Michael Haggerty; Martin Langhoff; Guilhem Bonnefille;
git@vger.kernel.org; users@cvs2svn.tigris.org
Subject: Re: Re: cvs2svn conversion directly to git ready for
experimentation
On 8/3/07, Patwardhan, Rajesh <rajesh.patwardhan@etrade.com> wrote:
Show 9 quoted lines
>
> 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?

Show 28 quoted lines
> 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
Show 7 quoted lines
> > 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
Show 5 quoted lines
> 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
Show 6 quoted lines
> 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
Show 15 quoted lines
> 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

Previous: Jon SmirlNext: Michael Haggerty
Message 36 of 40 in “cvs2svn conversion directly to git ready for experimentation”
  1. Michael HaggertyAug 1, 2007
  2. Johannes SchindelinAug 1, 2007
  3. Jakub NarebskiAug 1, 2007
  4. Michael HaggertyAug 2, 2007
  5. Jon SmirlAug 2, 2007
  6. Steffen ProhaskaAug 2, 2007
  7. Michael HaggertyAug 2, 2007
  8. Marko MacekAug 2, 2007
  9. Jon SmirlAug 2, 2007
  10. Oswald BuddenhagenAug 5, 2007
  11. Simon 'corecode' SchubertAug 2, 2007
  12. Steffen ProhaskaAug 2, 2007
  13. Simon 'corecode' SchubertAug 2, 2007
  14. Robin RosenbergAug 2, 2007
  15. Lübbe OnkenAug 2, 2007
  16. Lübbe OnkenAug 2, 2007
  17. Steffen ProhaskaAug 2, 2007
  18. Simon 'corecode' SchubertAug 2, 2007
  19. Michael HaggertyAug 2, 2007
  20. Simon 'corecode' SchubertAug 3, 2007
  21. Steffen ProhaskaAug 4, 2007
  22. Shawn O. PearceAug 3, 2007
  23. Michael HaggertyAug 2, 2007
  24. Linus TorvaldsAug 2, 2007
  25. Michael HaggertyAug 2, 2007
  26. Shawn O. PearceAug 3, 2007
  27. Jon SmirlAug 2, 2007
  28. Michael HaggertyAug 2, 2007
  29. Martin LanghoffAug 2, 2007
  30. Johannes SchindelinAug 3, 2007
  31. Steffen ProhaskaAug 3, 2007
  32. Steffen ProhaskaAug 3, 2007
  33. Michael HaggertyAug 3, 2007
  34. Patwardhan, RajeshAug 3, 2007
  35. Jon SmirlAug 3, 2007
  36. Patwardhan, RajeshAug 3, 2007
  37. Michael HaggertyAug 3, 2007
  38. Jon SmirlAug 3, 2007
  39. Jon SmirlAug 3, 2007
  40. Lübbe OnkenAug 2, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.