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

From: Thomas Leonard <talex5@gmail.com>
Date: Apr 8, 2008, 20:43 UTC
Message-ID: <cd53a0140804081343l4b791dc3x5fa3fb294af71621@mail.gmail.com>
In-Reply-To: <20080408171502.GA6163@atjola.homenet>

On 08/04/2008, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:

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

[...]

Show 5 quoted lines

>  > 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.

[...]

Show 19 quoted lines

>  > 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.

This is certainly true ;-)

>  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).

Show 11 quoted lines

>  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)

The script that made the releases simply did this ("." is the working copy):

svn cp -m "Released $VERSION" . http://...

Since each file in an svn working copy has its own revision (the last time it was changed), the branch ends up with multiple source revisions, even if the working copy is fully up-to-date and has no local changes.

Example:

cd /tmp svnadmin create test-repo svn mkdir file:///tmp/test-repo/trunk -m 'Setup' svn co file:///tmp/test-repo/trunk cd trunk touch foo bar svn add foo bar svn ci -m 'Start' echo hi > bar svn ci -m 'Update' svn cp . file:///tmp/test-repo/release -m 'Release' svn log -v file:///tmp/test-repo

The log shows:

------------------------------------------------------------------------
r4 | talex | 2008-04-08 21:35:44 +0100 (Tue, 08 Apr 2008) | 1 line
Changed paths:
   A /release (from /trunk:1)
   A /release/bar (from /trunk/bar:3)
   A /release/foo (from /trunk/foo:2)

Release

So, I don't think the metadata is broken in this case. Maybe other people don't create branches like this, but it seemed like the obvious way to do it at the time. Given this behaviour of svn, perhaps it would be better to take the highest version number as the branch point?

-- 
Dr Thomas Leonard		http://rox.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1