In main, resolving.

Should be fixed in 5efd447a9b8d.

> But 0.7->v0.7 should really be handled as deleting the old tag and creating a
new one.

I skipped that because convert extension does not currently work like that, it
updates the tags after the conversion process, not when they are created. Right
now, the tags directory is scanned backward and renaming followed, deleted tags
are still preserved.

I would not consider "commit in the tag itself, after a copy" (0.6.1) as
complete abuse, just as creating an unnamed branch and moving the tag to this
branch's head.

But 0.7->v0.7 should really be handled as deleting the old tag and creating a
new one.

Updating subject

Suppose we tag the trunk as 0.7, and we realize the 0.7 name doesn't follow the
tag name policy vX.Y. For repairing that, a svn user will use 'svn move' to
delete+copy the tag.

That corner case is not handled well by the convert code because when
converting, it sees the v0.1 (rev x) as a copy from a previous revision that
convert will never deal with (the tag commit that really copies the trunk tree
to the tags directory).

A real SVN repo with this corner case exists for real:
https://rawstudio.org/svn/rawstudio/

See tag 0.7 that became v0.7

Tag 0.6.1 is really not the same story as i would consider it as subversion copy
feature abuse (commit in the tag itself, after a copy).

The solution to this problem would be to recurse copy_from until the revision is
actually known by convert or reaches rev 0.