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

["Björn Steinbrink" <B.Steinbrink@gmx.de>]

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