Re: Fwd: [Bug 163341] Re: git-svn gets wrong parent revision for tags

On 2008.04.08 16:48:03 +0100, Thomas Leonard wrote:

Hi.

The git-svn Ubuntu packager asked me to forward this here.

Summary:

When converting a subversion repository to GIT using git-svn, the tags
do not have the right parent. Each tag should be identical to a trunk
revision (which it was copied from), but because git-svn uses an
earlier revision as the parent it appears that the same work was
duplicated on two branches.

Example:

git-svn clone https://zero-install.svn.sourceforge.net/svnroot/zero-install
-T trunk/0publish -r1890:2072 -b releases/0publish

The git branch comes from r1894, yet the svn log shows that in
includes files from r2070:

$ svn log https://zero-install.svn.sourceforge.net/svnroot/zero-install
-r2071 -v
r2071 | tal197 | 2007-11-10 19:40:45 +0000 (Sat, 10 Nov 2007) | 1 line
Changed paths:
   A /releases/0publish/0publish-0.12 (from /trunk/0publish:1968)
   R /releases/0publish/0publish-0.12/0publish (from
/trunk/0publish/0publish:2070)
   R /releases/0publish/0publish-0.12/0publish.xml (from
/trunk/0publish/0publish.xml:2070)
   R /releases/0publish/0publish-0.12/release.py (from
/trunk/0publish/release.py:2069)

Well, SVN recorded useless, broken metadata.

SVN itself believes that the branch was created from revision 1968. As
that revision didn't introduce any changes to trunk/0publish, there's no
commit for that revision in the git branch, so git-svn took the most
recent one instead (1894).

For the other three files, SVN reports that the files were replaced by
versions from another branch. There's no immediate way to tell whether
those replacements make the branch equal to the more recent version of
trunk. So git-svn does it the safe way and reproduces what SVN told it
to reproduce: A commit that creates a branch and changes some files.

I guess sth. like this happened on the svn end:
svn cp trunk/0publish releases/0publish (at rev. 1968)
svn cp trunk/0publish/release.py releases/0publish (at rev. 2069)
...
svn commit (whenever)

So the branch was "incrementally" created locally and SVN decided to
record the "Uh, I copied this from here to there" metacrap^H^H^H^Hdata,
of which git-svn made use. Hooray for rename/copy tracking.

You could maybe ask for an enhancement so that git-svn tries to figure
out if the provided metadata is broken and looks up a matching revision
in such a case. But I guess it's not worth the trouble and could lead to
other breakage along the way...

Björn