On 11/20/06, Martin Langhoff <martin.langhoff@xxxxxxxxx> wrote:
On 11/21/06, Jon Smirl <jonsmirl@xxxxxxxxx> wrote: > > I gather this means that the cvs2svn track hasn't been as productive > > as expected. Any remaining/unsolvable issues with it? I have been > > chronically busy on my e-learning projects, but don't discard coming > > back to this when I have some time. > > Look in this thread > [Fwd: Re: What's in git.git] > > There is a message in there that explains a problem that the cvs2svn > people aren't going to fix and it kills git. I see - thanks for the pointer. Sorry to hear others in the Moz project weren't so keen on hearing about alternatives to SVN. Long term only something like GIT seems viable for such a large project (in terms of community, branches/subprojects and codebase). Two remaining questions - Where can I get your latest code? :-)
I gave up on my cvs2git code, cvs2svn has been refactored so badly that it was too much trouble tracking. It would be easier to write it again. Most of the smarts from the import process is in the git-fastimport code which Shawn has. cvs2svn underwent a major algorithm change after I wrote the first version of git2svn. I can probably find the code if you really want it, but it will be leading you off in the wrong direction.
- I gather the moz cvs repo has some cases that require getting the symbol resolution right. Could this be performed as an extra pass / task?
Processing the symbols is integral to deciding how to build the change sets. Right now cvs2svn ignores the symbol dependency information and builds the change sets in a way that forces the mini-branches. That causes 60% of the 2,000 symbols in Mozilla CVS to end up as little branches. Look at the three commit example in the other thread to see exactly what the problem is. SVN hides the mini branch by creating a symbol like this: Symbol XXX, change set 70 copy All from change set 50 copy file A from change set 55 copy file B,C from change set 60 copy file D from change set 61 copy file E,F,G from change set 63 copy file H from change set 67 It has to do all of those copies because the change sets weren't constructed while taking symbol dependency information into account. Symbol XXX can't copy from change set 69 because commits from after the symbol was created are included in change sets 51-69.
Eventually the Moz crowd will outgrow SVN - perhaps we should be parsing the SVN dump format instead ;-) cheers, martin
-- 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