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

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

[Grmpf, the next time you drop from me Cc:, I'll not bother to
answer...]

On 2008.04.08 21:43:03 +0100, Thomas Leonard wrote:
> 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

Change the "." to "file:///tmp/test-repo/trunk" in the svn cp command
and you get:
Changed paths:
   A /release (from /trunk:3)

Seems more useful. No idea why SVN decides to record crap when you use
".", even when your working copy is clean.

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

Uhm, and what happens then, when you actually _did_ just copy over a
few files, but not all of them? Right, you get a branch to start at a
later revision and see a bunch of reverts. Equally broken.

Björn