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

[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 [off-list ref] wrote:

quoted

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

[...]

quoted

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

[...]

quoted

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

quoted

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

quoted

 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