Re: Repository for the conversion machinery

[Jason Merrill <jason at redhat dot com>]

On Thu, Oct 6, 2016 at 4:31 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Thu, 6 Oct 2016, Jason Merrill wrote:
>
>> After I ran into a couple of reposurgeon bugs and didn't hear back
>> from you, I started investigating rewriting the existing git svn
>> mirror with git filter-branch instead.  That seems an attractive
>> option, but not long afterward I needed to shift focus to front end
>
> I've used both git-svn (sometimes with git filter-branch) and reposurgeon
> for repository conversions.  My experience is that if there's anything at
> all complicated or messy about the history, using git-svn for the
> conversion is not a good idea, so I don't think that's an attractive
> option at all.

But we're already using git-svn, and it's fine.  Introducing another
tool just adds opportunities to be affected by new and different bugs.

Specifically, reposurgeon doesn't like subdirectory branches much more
than git-svn does, though I was able to work around that with
branchify (and some fixes in reposurgeon).  It discards branches with
no additional commits, and keeps other branches that were deleted in
SVN, though I was able to work around this with a postprocessing
script.

Most significantly, it fails to handle some commits (I noticed r137307
and r131989), leading to incorrect file content at the top of the
affected branches.  This is the issue that I didn't hear back from
Eric about, which led me to consider other approaches.  Fortunately it
marked them (as well as many others) with emptycommit tags for review.

But if you want to do it with reposurgeon, I won't complain.  I've
pushed my WIP to https://github.com/jicama/gcc-reposurgeon

Jason