{"thread":{"id":"22006","subject":"following untracked parents in git-svn","startedAt":"2009-12-22T10:28:17Z","lastAt":"2009-12-22T18:38:29Z","messageCount":2,"participants":["Robert Schiele","Eric Wong"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"130237","messageId":"20091222102815.GA12259@sigfpe.ibm.com","threadId":"22006","inReplyTo":null,"subject":"following untracked parents in git-svn","fromName":"Robert Schiele","fromEmail":"rschiele@gmail.com","sentAt":"2009-12-22T10:28:17Z","receivedAt":"2009-12-22T10:28:17Z","isPatch":false,"sender":{"key":"rschiele@gmail.com","avatar":"https://gravatar.com/avatar/409473567eb2287d5f0157b51f5b703994b347f24f92172e3a0588741c27a492?d=mp&s=160"},"body":"Hi Eric et al.,\n\nWhile using git-svn to work with a repository with a very complex history I\ndiscovered a very unfortunate behavior:\n\nIn general when a branch was derived (copied) from somewhere else git-svn\nfollows this parent branch and imports it.  If multiple branches do that\ngit-svn detects that the corresponding parrent branch already had been\nimported and reuses the imported data.  Unfortunately when the parent\ndirectory in the svn repository is not tracked as a branch in the svn-remote\nsection of the config file (for instance when it is just a subdirectory of a\ntracked branch) this situation is no longer detected and this parent branch is\nimported multiple times with the same result.  In a large repository this can\nincrease importing time drastically.\n\nMy analysis (as far as I understand the code) is that this is because the map\nfiles in .git/svn are indexed by their ref name in the git repository.\nUntracked branches are indexed by the name of their following branch ref name\nfollowed by @XX where XX is the revision number of the branch point.\nObviously with that scheme the index name for two branches following a common\nparent tree is different and thus an already imported tree is not correctly\ndetected.\n\nMy thoughts where now that this could potentially be fixed by not indexing\nthose map files by their ref name in the git repository but by their location\nin the original svn repository.  Given that my understanding of the git-svn\ncode is not good enough to decide about all the consequences of such a design\nchange I'd like to ask you whether you think this change would be a good idea\nor whether I might have overlooked a fundamental problem that makes it\nimpossible (or at least hard) to implement this idea.\n\nSince my description of the problem might be a bit confusing without an\nexample I created a very small svn repository that shows this problem.  A svn\nrepository dump for it is attached.  When importing this repository using the\nsvn-remote section\n\n[svn-remote \"svn\"]\n\turl = file:///dev/shm/x/svn1\n\tfetch = trunk:refs/remotes/trunk\n\tbranches = branches/*:refs/remotes/*\n\ttags = tags/*:refs/remotes/tags/*\n\nyou will get the following behavior during the import:\n\n$ git svn init -s file:///dev/shm/x/svn1\nInitialized empty Git repository in /dev/shm/x/git2/.git/\n$ git svn fetch\nr1 = 7920f3e7e70c9bb9d8a7caf28830c7ed205c20c6 (refs/remotes/trunk)\n\tA\tx/alpha\nr2 = db7ad1b41f1d2ad18d198b9a80d2606b27557faf (refs/remotes/trunk)\n\tA\tx/beta\nr3 = a35cab9c510f66d96437f21ecb738c93e0c6b793 (refs/remotes/trunk)\nFound possible branch point: file:///dev/shm/x/svn1/trunk/x => file:///dev/shm/x/svn1/branches/foo1, 2\nInitializing parent: refs/remotes/foo1@2\n\tA\talpha\nr2 = 5584693b5216dc1fa05f56455c67dfd61093ee43 (refs/remotes/foo1@2)\nFound branch parent: (refs/remotes/foo1) 5584693b5216dc1fa05f56455c67dfd61093ee43\nFollowing parent with do_switch\n\tA\tbeta\nSuccessfully followed parent\nr4 = d0cb7cfc1f69e52ecd39d8eb67518abe136b53d3 (refs/remotes/foo1)\nFound possible branch point: file:///dev/shm/x/svn1/trunk/x => file:///dev/shm/x/svn1/branches/foo2, 2\nInitializing parent: refs/remotes/foo2@2\n\tA\talpha\nr2 = 5584693b5216dc1fa05f56455c67dfd61093ee43 (refs/remotes/foo2@2)\nFound branch parent: (refs/remotes/foo2) 5584693b5216dc1fa05f56455c67dfd61093ee43\nFollowing parent with do_switch\n\tA\tbeta\nSuccessfully followed parent\nr5 = 181cb81070b816bef74adefa1bc4c451100a5eef (refs/remotes/foo2)\nChecked out HEAD:\n  file:///dev/shm/x/svn1/trunk r3\n\nAs you can see file:///dev/shm/x/svn1/trunk/x is imported twice.  For this\nsmall repository this is not a big issue but when this tree had a deep history\nin a large repository you wanted to avoid that.\n\nRobert\n"},{"id":"130251","messageId":"20091222183829.GA7412@dcvr.yhbt.net","threadId":"22006","inReplyTo":"20091222102815.GA12259@sigfpe.ibm.com","subject":"Re: following untracked parents in git-svn","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2009-12-22T18:38:29Z","receivedAt":"2009-12-22T18:38:29Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Robert Schiele <rschiele@gmail.com> wrote:\n> Hi Eric et al.,\n> \n> While using git-svn to work with a repository with a very complex history I\n> discovered a very unfortunate behavior:\n> \n> In general when a branch was derived (copied) from somewhere else git-svn\n> follows this parent branch and imports it.  If multiple branches do that\n> git-svn detects that the corresponding parrent branch already had been\n> imported and reuses the imported data.  Unfortunately when the parent\n> directory in the svn repository is not tracked as a branch in the svn-remote\n> section of the config file (for instance when it is just a subdirectory of a\n> tracked branch) this situation is no longer detected and this parent branch is\n> imported multiple times with the same result.  In a large repository this can\n> increase importing time drastically.\n> \n> My analysis (as far as I understand the code) is that this is because the map\n> files in .git/svn are indexed by their ref name in the git repository.\n> Untracked branches are indexed by the name of their following branch ref name\n> followed by @XX where XX is the revision number of the branch point.\n> Obviously with that scheme the index name for two branches following a common\n> parent tree is different and thus an already imported tree is not correctly\n> detected.\n\nHi Robert, I'm aware of this problem.  It's not hit too often, but\noccassional repositories I follow tend to hit this.\n\n> My thoughts where now that this could potentially be fixed by not indexing\n> those map files by their ref name in the git repository but by their location\n> in the original svn repository.  Given that my understanding of the git-svn\n> code is not good enough to decide about all the consequences of such a design\n> change I'd like to ask you whether you think this change would be a good idea\n> or whether I might have overlooked a fundamental problem that makes it\n> impossible (or at least hard) to implement this idea.\n\nYour idea sounds like it should work.  Unfortunately the code is a mess\nand I've been lazy and lacking time/sufficient motivation to clean it\nup, but I'd be glad to accept patches since the test coverage is pretty\ngood.\n\n-- \nEric Wong\n"}]}