[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@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 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 -- 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
