On 2008.04.08 16:48:03 +0100, Thomas Leonard wrote: > Hi. > > The git-svn Ubuntu packager asked me to forward this here. > > Summary: > > 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. > > Example: > > 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. 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) So the branch was "incrementally" created locally and SVN decided to record the "Uh, I copied this from here to there" metacrap^H^H^H^Hdata, of which git-svn made use. Hooray for rename/copy tracking. You could maybe ask for an enhancement so that git-svn tries to figure out if the provided metadata is broken and looks up a matching revision in such a case. But I guess it's not worth the trouble and could lead to other breakage along the way... Björn -- 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
