{"thread":{"id":"20222","subject":"git svn fetches the same revision multiple times for non-trunk branches","startedAt":"2009-07-24T21:53:38Z","lastAt":"2009-07-28T09:41:22Z","messageCount":4,"participants":["Robert Zeh","Eric Wong"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"118661","messageId":"CEAA2460-501C-48C1-BC33-B92A68C2161B@gmail.com","threadId":"20222","inReplyTo":null,"subject":"git svn fetches the same revision multiple times for non-trunk branches","fromName":"Robert Zeh","fromEmail":"robert.a.zeh@gmail.com","sentAt":"2009-07-24T21:53:38Z","receivedAt":"2009-07-24T21:53:38Z","isPatch":false,"sender":{"key":"robert.a.zeh@gmail.com","avatar":"https://avatars.githubusercontent.com/u/174737?v=4"},"body":"I am seeing git svn fetch repeatedly retrieve the same Subversion \nrevisions when it finds branches in our Subversion repository. We are \nusing the standard Subversion repository layout, with top level / \ntrunk, /tags, and /branches directories (and the git repository was \ncreated with 'git svn init -s'). However, the problematic branches are \noften copies made from a subdirectory inside of trunk, instead of trunk.\n\nThe git svn fetch output typically looks like:\n\n\nR2537 = d5b22e956157af036d4112e42e8fb927e45758c8 (trunk)\n M Enterprise/VC/lib/SymbolVenue.cpp\nr2538 = cfed4ca0491da0b732f32bfff72ba678450a0915 (trunk)\nFound possible branch point: http://repo/prod_repos/trunk/Enterprise/ \nVC => http://repo/prod_repos/branches/file_conversion, 2523\nW: Refspec glob conflict (ref: refs/remotes/scripter@832):\nexpected path: branches/scripter@832\n real path: trunk/Enterprise/Python\nContinuing ahead with trunk/Enterprise/Python\nW: Refspec glob conflict (ref: refs/remotes/trunk):\nexpected path: branches/trunk\n real path: trunk\nContinuing ahead with trunk\nInitializing parent: file_conversion@2523\n A gc/QuoteService.cpp\n A gc/TestSuite.h\n A gc/quote_svc.pro\n A gc/QuoteService.h\n.....\n\nr1 = d349ed8cb2d76596fe2b83224986275be4600fad (QuoteSvcFix442@2698)\n D gc/FixMessageLogger.h\n.....\nr5 =\nr19 =\nr20 =\n.....\n\n\n\nAnd we are back at revision 1. git svn fetch then continues to fetch \nrevisions until it reaches the revision that created the branch.\n\nWhat am I doing wrong? Is there anyway for me to tell git svn fetch to \nnot retrieve revisions it has already pulled? This is converting my \nimport time from O(n) to O(n^2).\n\nRobert\n"},{"id":"118712","messageId":"20090725105111.GB13534@dcvr.yhbt.net","threadId":"20222","inReplyTo":"CEAA2460-501C-48C1-BC33-B92A68C2161B@gmail.com","subject":"Re: git svn fetches the same revision multiple times for non-trunk branches","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2009-07-25T10:51:11Z","receivedAt":"2009-07-25T10:51:11Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Robert Zeh wrote:\n> I am seeing git svn fetch repeatedly retrieve the same Subversion \n> revisions when it finds branches in our Subversion repository. We are \n> using the standard Subversion repository layout, with top level /trunk, \n> /tags, and /branches directories (and the git repository was created with \n> 'git svn init -s'). However, the problematic branches are often copies \n> made from a subdirectory inside of trunk, instead of trunk.\n\nHi Robert,\n\nYes, this is a known problem with some repositories and there's no\nautomatic/easy[1] way to handle it with globbing tags/* or branches/*.\n\nYou can try to track each tagged project independently or to setup\nindividual fetche lines (like the one generated for trunk). in\n.git/config for each tag/branch.\n\n[1] - Unfortunately SVN allows way too much freedom and thus ambiguity\nin how it treats tags/branches and that doesn't allow mapping those\nthings to git very easily.\n\n-- \nEric Wong\n"},{"id":"118913","messageId":"E9365F62-FD6F-4770-B177-9B8F0413C12C@gmail.com","threadId":"20222","inReplyTo":"20090725105111.GB13534@dcvr.yhbt.net","subject":"Re: git svn fetches the same revision multiple times for non-trunk branches","fromName":"Robert Zeh","fromEmail":"robert.a.zeh@gmail.com","sentAt":"2009-07-27T23:56:17Z","receivedAt":"2009-07-27T23:56:17Z","isPatch":false,"sender":{"key":"robert.a.zeh@gmail.com","avatar":"https://avatars.githubusercontent.com/u/174737?v=4"},"body":"So is the basic problem that the history of the branch is unknown and \nwe have to retrieve the history?\n\nRobert\nOn Jul 25, 2009, at 5:51 AM, Eric Wong wrote:\n\n> Robert Zeh wrote:\n>> I am seeing git svn fetch repeatedly retrieve the same Subversion\n>> revisions when it finds branches in our Subversion repository. We are\n>> using the standard Subversion repository layout, with top level / \n>> trunk,\n>> /tags, and /branches directories (and the git repository was \n>> created with\n>> 'git svn init -s'). However, the problematic branches are often \n>> copies\n>> made from a subdirectory inside of trunk, instead of trunk.\n>\n> Hi Robert,\n>\n> Yes, this is a known problem with some repositories and there's no\n> automatic/easy[1] way to handle it with globbing tags/* or branches/*.\n>\n> You can try to track each tagged project independently or to setup\n> individual fetche lines (like the one generated for trunk). in\n> .git/config for each tag/branch.\n>\n> [1] - Unfortunately SVN allows way too much freedom and thus ambiguity\n> in how it treats tags/branches and that doesn't allow mapping those\n> things to git very easily.\n>\n> -- \n> Eric Wong\n"},{"id":"118938","messageId":"20090728094122.GB25863@dcvr.yhbt.net","threadId":"20222","inReplyTo":"E9365F62-FD6F-4770-B177-9B8F0413C12C@gmail.com","subject":"Re: git svn fetches the same revision multiple times for non-trunk branches","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2009-07-28T09:41:22Z","receivedAt":"2009-07-28T09:41:22Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Robert Zeh wrote:\n> So is the basic problem that the history of the branch is unknown and we \n> have to retrieve the history?\n\nYes, or rather it's not known that it's a branch/tag:\n\nSay you have something like this:\n\n /trunk/client\n /trunk/server\n /trunk/design_docs_specs_and_whatnot\n /tags/client_1.0\n /tags/client_1.1\n /tags/server_1.0\n /tags/server_1.1\n\nBut you're tracking /trunk, /tags/*, /branches/* like you normally do,\nall the developers usually work off /trunk anyways because /client\nchanges are tied to /server and they have both checked out and\nthey also need to read/update the docs common to the server and\nclient.\n\nHowever, tags are deployed to separate machines and the docs don't need\nto be; so they're tagged separately off their respective working\ndirectories.\n\nSo when git svn sees /tags/client_1.0, it'll think that it was tagged\noff /trunk and not /trunk/client. But since you're tracking /trunk and\nnot /trunk/client, it can't find history in /trunk. So it starts\ntracking /trunk/client anew without taking /trunk into account.\n\nSo git svn will create a ref that looks like tags/client_1.0@REV. What\ngit svn could (and if somebody found time to work on it) is to reuse\nany/first tags/client_1.0@REV tags it finds.\n\nAnd simply using the existing git history of /trunk to see the history\nof /trunk/client is suboptimal, too, because /trunk/client could've\noriginally come from /client (an actual case I've encountered) before\n/trunk existed.\n\nRemember, unlike SVN, git doesn't track directory renames (or renames,\nor directories at all) for that matter. This is a huge fundamental\ndifference between the two systems and mapping between them was one of\nthe greatest difficulties I had with git svn.\n\nThe very first version of git svn was something that would only ever\ndumbly track one directory (and it still supports that mode of\noperation, just don't pass any options to init/clone). So a git working\ntree might have trunk, branches/*, tags/* all on the filesystem. It's\na very big working tree in some cases, but it was the easiest to\nimplement because it didn't do anything smart.\n\n-- \nEric Wong\n"}]}