Joseph Myers <jos...@codesourcery.com>:
> On Wed, 27 Nov 2019, Maxim Kuvyrkov wrote:
>
> > IMO, we should aim to convert complete SVN history frozen at a specific
> > point. So that if we don't want to convert some of the branches or tags
> > to git, then we should delete them from SVN repository before
> > conversion.
>
> Sure, we could do that. Eric, can you confirm that, with current
> reposurgeon, if a branch or tag was deleted in SVN and does not appear in
> the final revision of /branches or /tags, it should not appear in the
> resulting converted repository, so that any cases where reposurgeon fails
> to reflect such a deletion-in-SVN should be reported as a reposurgeon bug?
Confirmed.
The ontological mismatch between the Subversion and Git data models actually
*forces* us to pick a preferred view and discard tags and branches
that are not visible from that view. For obvious reasons reposurgeon chooses
the view backwards from the end of the history, so it will be the most
recent incarnation of each tag and branch that you see.
There is an alternative, the --nobranch conversion. This would preserve the
entire historical structure, including deleted tags and branches, but the
cost is that the conversion doesn't have git tags and branches itself -
it's just one big directory history on /refs/heads/master. While this is useful
for forensics, it is not a conversion you'd want to use for production.
> And that the same applies where a branch or tag was renamed - that only
> the new name, not the old one, should appear in the converted repository?
Confirmed, see above.
> There are quite a few deletions in gcc.lift for tags that do not actually
> appear in /tags in the current SVN repository, but I'm not sure how many
> are actually relevant with current reposurgeon.
Many will not be. The recipe file predates the point at which I came
to fully undersrand the ramifications of tag delete/recreate sequences.
I haven't cleaned it up yet because chasing down the last few bugs in
the analyzer is more important.
I'll leave it to you guys to discuss the policy issues. In general I
think you can safely throw out branchphoint tagas and emptycommits;
reposurgeon only preserves those on the theoretical chance that there
might be something interesting in the change comments.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
