Richard Earnshaw (lists) <richard.earns...@arm.com>: > Well a lot of that is a property of the conversion tool. git svn does a > relatively poor job of anything other than straight history (I believe it > just ignores the non-linear information.
Yes, svn-git does a *terrible* job on anything other than linear history. That is a major reason I'm busting my hump to get the conversion done. It would be very sad if you guys fell into using that. It does a tolerable job of live gatewaying on simple histories, but read this: http://esr.ibiblio.org/?p=6778 > I don't believe any tool can > recreate information for cherry-picking unless it's recorded in the SVN > meta-data. Eric would be better placed to comment here. You are correct, there is nothing practical that can be done in the absence of svn:mergeinfo and svnmerge-integrated properties. > My own observation is that when the SVN commits have merge meta-data, > reposurgeon will pick this up and create links across to the relevant > branches. It does, however seem to create far more links than a traditional > git merge would do, especially when a sequence of commits are referenced. I > don't know if that's essentially unfixable, or if it's something Eric > intends to work on; but I've seen some cases where there are dozens of links > back to a simple sequence of svn commits and where, I suspect, a single link > back to the most recent of that sequence would be all that's really wanted. First I have heard of this. The intent of the present mergeinfo handing is that it looks for mergeinfo declarations that are topologically equivalent to branch merges (that is, they merge all revisions on a source branch rather than cherry-picking isolated revisions) and rendering those as gitspace merge links. There is no attempt to create links corresponding to Subversion cherry picks, as this does not fit the Git DAG model. I have cases that demonstrate this feature working in my test suite, but they are relatively small and artificial. I would not describe my mergeinfo handling as well-tested compared to the rest of the analyzer, and I can thus easily believe your bug report. What I need to troubleshoot this is a test case that is not trivial but of a manageable size - over a couple hundred commits the volume of diagnostics just overwhelms a Mark One Eyeball. Many of my test cases were trimmed to that size by doing stripping and topological reduction on real repositories; I have a tool for this. Do you have a real repository in mind I can start with? The whole gcc history is too huge, but if you were able to tell me that the bug is exhibited within a few thousand commits of origin and point at where, that I could work with. An issue filed on the reposurgeon tracker would be appreciated. -- <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
