Richard Earnshaw (lists) <richard.earns...@arm.com>:
> Well, personally, I'd rather we didn't throw away data we have in our
> current SVN repo unless it's unpresentable in the final conversion.
I agree with this philosophy. You will have noticed by now, I hope,
that reposurgeon peserves as much as it can, leaving deletions to be
a matter of user policy.
In the normal case, reposurgeon could save its users a significant
amount of work by being more aggressive about automatically deleting
remnant bits that are merely *very unlikely* to be useful. I deliberately
refused to go thar route.
> Merge info is not one of those cases.
Sometimes. Some Subversion mergeinfo operations map to Git's
branch-centric merging. Many do not, corresponding to cherry-picks
that cannot be expressed in a Git history.
Reposurgeon does a correct but not complete job of translating
mergeinfos that compose into branch merges. It handles the simple,
cmmon cases and punts the tricky ones.
More coverage would theoretically be possible, but I don't
have the faintest clue what a general resolution rule would
look like. Except I'm pretty sure the problem is bitchy-hard
and the solution really easy to get subtly wrong.
Frankly, I don't want to touch this mess with insulated
tongs. Somebody would have to offer me serious money to
compensate for the expected level of pain.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
