{"thread":{"id":"30119","subject":"Importing a subversion repository where some branches come from trunk subtrees","startedAt":"2012-03-31T09:28:42Z","lastAt":"2012-03-31T10:23:52Z","messageCount":3,"participants":["frnchfrgg.jr","Andrew Sayers","Julien \"_FrnchFrgg_\" Rivaud"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"188241","messageId":"CABaB1pJNs1FL6=CbJ97pq7O=jKK=G_4t-vsx-2c4vHXsuzr40g@mail.gmail.com","threadId":"30119","inReplyTo":null,"subject":"Importing a subversion repository where some branches come from trunk subtrees","fromName":"frnchfrgg.jr","fromEmail":"frnchfrgg.jr@gmail.com","sentAt":"2012-03-31T09:28:42Z","receivedAt":"2012-03-31T09:28:42Z","isPatch":false,"sender":{"key":"frnchfrgg.jr@gmail.com","avatar":null},"body":"Hello,\n\nI noticed that a svn branch made out of a subtree of trunk confuses\ngit-svn which fetches the whole history a second time (restricted to\nthat subtree). Unfortunately this kind of strange branching has been\nrepeatedly made in the Blender svn repository and I can end up with 5\nor 6 times the full history from rev1 to rev20000, which makes the\nconversion even slower, the mirror bigger and loooong to clone and\nbisects completely unuseful.\n\nIs this expected ? Or when git-svn identified the svn revision number\nof the parent and there already is a git commit imported from this\nrevision, should it use that commit as the parent ? This would make\nthe branch creation commit have a big \"mangling paths\" diff with its\nparent but I think it is logical.\n\nThat also means that when importing a revision, git-svn should always\nimport the state of the whole tree (up to the branch, tag, or trunk\nroot) and not only a part of it.\n\nI have made a 4-revision sample svn repo which exhibits the problem,\nbut it is quite simple to reproduce.\n\nIs there a good reason for this behaviour (in other cases I can't think of) ?\n\n\nJulien \"_FrnchFrgg_\" Rivaud\n"},{"id":"188244","messageId":"4F76D769.7040301@pileofstuff.org","threadId":"30119","inReplyTo":"CABaB1pJNs1FL6=CbJ97pq7O=jKK=G_4t-vsx-2c4vHXsuzr40g@mail.gmail.com","subject":"Re: Importing a subversion repository where some branches come from trunk subtrees","fromName":"Andrew Sayers","fromEmail":"andrew-git@pileofstuff.org","sentAt":"2012-03-31T10:07:37Z","receivedAt":"2012-03-31T10:07:37Z","isPatch":false,"sender":{"key":"andrew-git@pileofstuff.org","avatar":null},"body":"I'm not an expert on git-svn internals, but I believe sub-project\nbranches are a limitation of its branching implementation.  svn-fe\ndoesn't have this problem at the downloading stage (and will do 20,000\nrevisions much quicker than git-svn), but requires you to split branches\nout by hand.\n\nI'm currently trying to document these strange edge cases as part of an\nongoing effort to add branch information on top of svn-fe's output.\nWould you mind taking a look at [1] and letting me know if it's an\nunderstandable description of your problem?  Improvements and other edge\ncases are very much welcome, and I hope to have something in the coming\nmonths that tackles these issues.\n\n\t- Andrew\n\n[1]https://github.com/andrew-sayers/SVN-Branching-Language/blob/master/t/advanced/subproject_branch.sh\n"},{"id":"188245","messageId":"CABaB1pJumh8Oyx3Et+kjOLoW6x55Fg5gnehKwh+2gHHwHoTz9g@mail.gmail.com","threadId":"30119","inReplyTo":"4F76D769.7040301@pileofstuff.org","subject":"Re: Importing a subversion repository where some branches come from trunk subtrees","fromName":"Julien \"_FrnchFrgg_\" Rivaud","fromEmail":"frnchfrgg.jr@gmail.com","sentAt":"2012-03-31T10:23:52Z","receivedAt":"2012-03-31T10:23:52Z","isPatch":false,"sender":{"key":"frnchfrgg.jr@gmail.com","avatar":null},"body":"On Sat, Mar 31, 2012 at 12:07 PM, Andrew Sayers\n<andrew-git@pileofstuff.org> wrote:\n\n> Would you mind taking a look at [1] and letting me know if it's an\n> understandable description of your problem?\n> [1]https://github.com/andrew-sayers/SVN-Branching-Language/blob/master/t/advanced/subproject_branch.sh\n\nYes, it indeed is a good description of the action that causes git-svn\nto duplicate history (on the other hand, the cases I saw from the\nblender repo seem more like overlooks and/or straight mistakes)\n\n_FrnchFrgg_\n"}]}