It seems the tools at git.apache.org use the new svn info to notice merges and such, so those tools are superior to git-svn (assuming it's not just a newer version of git-svn itself).
B. On 8 August 2011 19:22, Paul Davis <[email protected]> wrote: > On Mon, Aug 8, 2011 at 1:14 PM, Dustin Sallings <[email protected]> wrote: >> >> On July 31, 2011 9:29:40 AM, Paul Davis wrote: >> >>> 4. Before making the complete switch I'll end up making a handful of >>> Git clones to check that our history is preserved. I plan on writing a >>> script to make Graphviz images of the branch history and so on, but >>> having people volunteer to look back at the history to spot errors >>> would be helpful as well. >> >> >> I believe I can be of help if you need any. >> >> I've done a lot of very complicated git conversions (including things >> like taking memcached git dev and transplanting it above an older subversion >> conversion that was discovered later and another that involved merging 24 >> different git repos that were moving concurrently at the root level into a >> single that had 24 subdirectories and linear history) and really got to know >> git well along the way. >> >> If there's any hard work to do here, I'm sure I've enjoyed doing it >> before. >> >> [btw, if anyone wants to see what a 24-way octopus merge looks like: >> http://dustin.github.com/2008/12/31/archaeology.html ] >> >> -- >> dustin sallings >> >> >> >> > > Nice! Any hints you have about validating SVN->Git conversions or > tooling would be greatly appreciated. I don't really have much other > than the obvious Graphviz plotting tool. Beyond that I don't have > anything other than getting each TLP to verify their own history. > > I'm also not sure if it makes a difference, but the ASF SVN repo is > one huge monolithic thing, so it's a lot of project histories > intertwined which I'm looking forward to finding awesome conversion > bugs with. >
