On 08/04/2008, Björn Steinbrink <B.Steinbrink@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
