On 2008.04.09 11:39:17 +0100, Thomas Leonard wrote: > On 09/04/2008, Björn Steinbrink <B.Steinbrink@xxxxxx> wrote: > > On 2008.04.08 21:43:03 +0100, Thomas Leonard wrote: > > > 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. > > That's good advice, but I'm wondering how to convert my existing svn > repositories to GIT. I'd probably patch git-svn locally once and revert it after the import, if your suggested change really makes sense for your repo. Another option would be to adjust the branches afterwards, but that's probably awkward in your case. Maybe a patch that allows to toggle the branch creation logic would be accepted as well, dunno. > > > 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. > > Sure, if you create a situation that GIT can't represent then there's > nothing much git-svn can do. > > However, when there are different source revisions: > > - Taking the highest revision will give correct results in the common > case, and "equally broken" results in the uncommon case. > > - Taking any other revision (the current behaviour) is guaranteed to > give the wrong result. There's no way a branch that was created with a > file from revision 6 can possibly be a branch of revision 5, for > example. Sure it can be. svn co $repo full-repo-here cd full-repo-here svn cp trunk branches/b1 (at rev 5) echo 123 > trunk/foo # (new file) echo 456 > trunk/bar # 431 other files changed (exaggeration ;-)) svn commit trunk -m "Committing trunk only, with 433 files changed" svn cp trunk/foo branches/b1 svn commit branches/b1 -m "Committing b1." b1 branched at rev 5, but has a single file from rev 6. Currently, git-svn would create the branch starting at rev5, with the addition of "foo" on top. Your suggested change would make it branch at rev6 and revert 432 files. The fact that svn just has directory copies as branches makes all kinds of junk possible ;-) > Also, the current behaviour can be wildly out (e.g. revision 1894 when > it should have been 2070, in the previous real example). The highest > revision is unlikely to be far off. How many "interesting" revisions was it off by? 3? As the revision numbers in svn are shared throughout the whole repo, your example sounds far worse than it really is. And for locally prepared branches (I've actually heard of people doing that, like in my example above), it can happen for your way to be way more off than the current 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
