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

["Thomas Leonard" <talex5@gmail.com>]

On 08/04/2008, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> On 2008.04.08 16:48:03 +0100, Thomas Leonard wrote:
[...]
>  > 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.
[...]
>  > 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).

>  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