{"thread":{"id":"9775","subject":"git-svn and a nested branches folder","startedAt":"2007-09-04T14:42:50Z","lastAt":"2007-09-05T10:15:17Z","messageCount":11,"participants":["Russ Brown","David Kastrup","Peter Baumann","Eric Wong"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"52453","messageId":"46DD6EEA.9010304@gmail.com","threadId":"9775","inReplyTo":null,"subject":"git-svn and a nested branches folder","fromName":"Russ Brown","fromEmail":"pickscrape@gmail.com","sentAt":"2007-09-04T14:42:50Z","receivedAt":"2007-09-04T14:42:50Z","isPatch":false,"sender":{"key":"pickscrape@gmail.com","avatar":null},"body":"Hi,\n\nI'm having some trouble with using git-svn to fetch a repository, and I\nthink it's because the repository doesn't store branches as a flat list\ndirectly under the 'branches' directory.\n\nBasically, we have a structure like this:\n\n|\n+-trunk\n+-tags\n+-branches\n + category-a\n + branch-a\n + branch-b\n + category-b\n + branch-c\n + branch-d\n\netc. category-a and category-b are simple directories created using svn\nmkdir. The branches are created using svn cp.\n\nIt helps us to organise the branches better, but the rationale is\nbesides the point. The problem is that git-svn seems to want to treat\ncategory-a and category-b as branches, which isn't right at all. As a\nresult, git-svn seems to skip most (if not all) revisions that occur in\nthese directories and creates a lot of entries in unhandled.log.\n\nI've also encountered an index corruption in one of the\n.git/svn//index files which I think it probably related.\n\nI've had a quick look at the source myself, but perl isn't my strong\npoint. What I think it should do is something like recurse down the tree\nfrom the directory given looking for folders that copy from trunk (or\nsome other branch that already exists). That would work perfectly well\nfor the default flat branch storage method as well as the one we use.\n\nThe only other problem is in branch naming, which could clash if you\nonly use the outer-most directory name, so I'd suggest something that\ninvolves concatenating the folders in the path relative to 'branches' to\nkeep them unique (if git can handle slashes in branch names then all the\nbetter).\n\nThanks for reading.\n\n-- \n\nRuss\n"},{"id":"52455","messageId":"86veaqebf1.fsf@lola.quinscape.zz","threadId":"9775","inReplyTo":"46DD6EEA.9010304@gmail.com","subject":"Re: git-svn and a nested branches folder","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-04T14:46:10Z","receivedAt":"2007-09-04T14:46:10Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Russ Brown writes:\n\n> I'm having some trouble with using git-svn to fetch a repository, and I\n> think it's because the repository doesn't store branches as a flat list\n> directly under the 'branches' directory.\n>\n> Basically, we have a structure like this:\n>\n> |\n> +-trunk\n> +-tags\n> +-branches\n> + category-a\n> + branch-a\n> + branch-b\n> + category-b\n> + branch-c\n> + branch-d\n>\n> etc. category-a and category-b are simple directories created using svn\n> mkdir. The branches are created using svn cp.\n>\n> It helps us to organise the branches better, but the rationale is\n> besides the point. The problem is that git-svn seems to want to\n> treat category-a and category-b as branches, which isn't right at\n> all. As a result, git-svn seems to skip most (if not all) revisions\n> that occur in these directories and creates a lot of entries in\n> unhandled.log.\n\nSo what did you specify in your .git/config file regarding the svn\nstructure?\n\n-- \nDavid Kastrup\n"},{"id":"52460","messageId":"46DD718C.7060908@gmail.com","threadId":"9775","inReplyTo":"86veaqebf1.fsf@lola.quinscape.zz","subject":"Re: git-svn and a nested branches folder","fromName":"Russ Brown","fromEmail":"pickscrape@gmail.com","sentAt":"2007-09-04T14:54:04Z","receivedAt":"2007-09-04T14:54:04Z","isPatch":false,"sender":{"key":"pickscrape@gmail.com","avatar":null},"body":"David Kastrup wrote:\n> Russ Brown writes:\n> \n>> I'm having some trouble with using git-svn to fetch a repository, and I\n>> think it's because the repository doesn't store branches as a flat list\n>> directly under the 'branches' directory.\n>>\n>> Basically, we have a structure like this:\n>>\n>> |\n>> +-trunk\n>> +-tags\n>> +-branches\n>> + category-a\n>> + branch-a\n>> + branch-b\n>> + category-b\n>> + branch-c\n>> + branch-d\n>>\n>> etc. category-a and category-b are simple directories created using svn\n>> mkdir. The branches are created using svn cp.\n>>\n>> It helps us to organise the branches better, but the rationale is\n>> besides the point. The problem is that git-svn seems to want to\n>> treat category-a and category-b as branches, which isn't right at\n>> all. As a result, git-svn seems to skip most (if not all) revisions\n>> that occur in these directories and creates a lot of entries in\n>> unhandled.log.\n> \n> So what did you specify in your .git/config file regarding the svn\n> structure?\n> \n\nI specified the 'branches' directory, but that's because earlier in the\nlife of the repo we did just do the flat branch layout, but decided to\nmake it more structured once that got unwieldy.\n\nIs it possible to specify more than one folder for the branches option?\n\n-- \n\nRuss\n"},{"id":"52462","messageId":"86r6leeaq7.fsf@lola.quinscape.zz","threadId":"9775","inReplyTo":"46DD718C.7060908@gmail.com","subject":"Re: git-svn and a nested branches folder","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-04T15:01:04Z","receivedAt":"2007-09-04T15:01:04Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Russ Brown writes:\n\n> David Kastrup wrote:\n>> Russ Brown writes:\n>> \n>>> I'm having some trouble with using git-svn to fetch a repository, and I\n>>> think it's because the repository doesn't store branches as a flat list\n>>> directly under the 'branches' directory.\n>>>\n>>> Basically, we have a structure like this:\n>>>\n>>> |\n>>> +-trunk\n>>> +-tags\n>>> +-branches\n>>> + category-a\n>>> + branch-a\n>>> + branch-b\n>>> + category-b\n>>> + branch-c\n>>> + branch-d\n>>>\n>>> etc. category-a and category-b are simple directories created using svn\n>>> mkdir. The branches are created using svn cp.\n>>>\n>>> It helps us to organise the branches better, but the rationale is\n>>> besides the point. The problem is that git-svn seems to want to\n>>> treat category-a and category-b as branches, which isn't right at\n>>> all. As a result, git-svn seems to skip most (if not all) revisions\n>>> that occur in these directories and creates a lot of entries in\n>>> unhandled.log.\n>> \n>> So what did you specify in your .git/config file regarding the svn\n>> structure?\n>\n> I specified the 'branches' directory, but that's because earlier in\n> the life of the repo we did just do the flat branch layout, but\n> decided to make it more structured once that got unwieldy.\n\nCough, cough. _What_ did you specify in your .git/config file\nregarding the svn structure? Please quote the section.\n\n> Is it possible to specify more than one folder for the branches\n> option?\n\nIt is possible to adapt the config section to the actual layout. If\nnot otherwise, by starting with\ngit svn init\nwith a clean slate, editing the config file, and only then actually\nfetching stuff.\n\nHowever, git-svn will not magically start guessing that you changed\nyour structure around. You have to edit the configuration\nappropriately.\n\n-- \nDavid Kastrup\n"},{"id":"52467","messageId":"46DD77F2.3040000@gmail.com","threadId":"9775","inReplyTo":"86r6leeaq7.fsf@lola.quinscape.zz","subject":"Re: git-svn and a nested branches folder","fromName":"Russ Brown","fromEmail":"pickscrape@gmail.com","sentAt":"2007-09-04T15:21:22Z","receivedAt":"2007-09-04T15:21:22Z","isPatch":false,"sender":{"key":"pickscrape@gmail.com","avatar":null},"body":"David Kastrup wrote:\n> Russ Brown writes:\n> \n>> David Kastrup wrote:\n>>> Russ Brown writes:\n>>>\n>>>> I'm having some trouble with using git-svn to fetch a repository, and I\n>>>> think it's because the repository doesn't store branches as a flat list\n>>>> directly under the 'branches' directory.\n>>>>\n>>>> Basically, we have a structure like this:\n>>>>\n>>>> |\n>>>> +-trunk\n>>>> +-tags\n>>>> +-branches\n>>>> + category-a\n>>>> + branch-a\n>>>> + branch-b\n>>>> + category-b\n>>>> + branch-c\n>>>> + branch-d\n>>>>\n>>>> etc. category-a and category-b are simple directories created using svn\n>>>> mkdir. The branches are created using svn cp.\n>>>>\n>>>> It helps us to organise the branches better, but the rationale is\n>>>> besides the point. The problem is that git-svn seems to want to\n>>>> treat category-a and category-b as branches, which isn't right at\n>>>> all. As a result, git-svn seems to skip most (if not all) revisions\n>>>> that occur in these directories and creates a lot of entries in\n>>>> unhandled.log.\n>>> So what did you specify in your .git/config file regarding the svn\n>>> structure?\n>> I specified the 'branches' directory, but that's because earlier in\n>> the life of the repo we did just do the flat branch layout, but\n>> decided to make it more structured once that got unwieldy.\n> \n> Cough, cough. _What_ did you specify in your .git/config file\n> regarding the svn structure? Please quote the section.\n> \n\nErm, sorry.\n\n[svn-remote \"svn\"]\n url = svn://svn..com\n fetch = trunk:refs/remotes/trunk\n branches = branches/*:refs/remotes/*\n tags = tags/*:refs/remotes/tags/*\n\n(URL changed in case it annoys my employers)\n\nI didn't write this by hand: it was generated by git-svn init.\n\n>> Is it possible to specify more than one folder for the branches\n>> option?\n> \n> It is possible to adapt the config section to the actual layout. If\n> not otherwise, by starting with\n> git svn init\n> with a clean slate, editing the config file, and only then actually\n> fetching stuff.\n> \n> However, git-svn will not magically start guessing that you changed\n> your structure around. You have to edit the configuration\n> appropriately.\n> \n\nThat's why I suggested that a method involving detecting branches based\non whether the directory is a copy of trunk or another branch might\n'magically' work in all scenarios. I've used a similar branch 'scanning'\ntechnique before for a different reason. But I realise there may be\ntechnical reasons as to why that might not be possible.\n\n-- \n\nRuss\n"},{"id":"52498","messageId":"20070904174006.GB4538@xp.machine.xx","threadId":"9775","inReplyTo":"46DD77F2.3040000@gmail.com","subject":"Re: git-svn and a nested branches folder","fromName":"Peter Baumann","fromEmail":"peter@hofmann.stw.uni-erlangen.de","sentAt":"2007-09-04T17:40:06Z","receivedAt":"2007-09-04T17:40:06Z","isPatch":false,"sender":{"key":"peter@hofmann.stw.uni-erlangen.de","avatar":null},"body":"On Tue, Sep 04, 2007 at 10:21:22AM -0500, Russ Brown wrote:\n> David Kastrup wrote:\n> > Russ Brown writes:\n> > \n> >> David Kastrup wrote:\n> >>> Russ Brown writes:\n> >>>\n> >>>> I'm having some trouble with using git-svn to fetch a repository, and I\n> >>>> think it's because the repository doesn't store branches as a flat list\n> >>>> directly under the 'branches' directory.\n> >>>>\n> >>>> Basically, we have a structure like this:\n> >>>>\n> >>>> |\n> >>>> +-trunk\n> >>>> +-tags\n> >>>> +-branches\n> >>>> + category-a\n> >>>> + branch-a\n> >>>> + branch-b\n> >>>> + category-b\n> >>>> + branch-c\n> >>>> + branch-d\n> >>>>\n> >>>> etc. category-a and category-b are simple directories created using svn\n> >>>> mkdir. The branches are created using svn cp.\n> >>>>\n> >>>> It helps us to organise the branches better, but the rationale is\n> >>>> besides the point. The problem is that git-svn seems to want to\n> >>>> treat category-a and category-b as branches, which isn't right at\n> >>>> all. As a result, git-svn seems to skip most (if not all) revisions\n> >>>> that occur in these directories and creates a lot of entries in\n> >>>> unhandled.log.\n> >>> So what did you specify in your .git/config file regarding the svn\n> >>> structure?\n> >> I specified the 'branches' directory, but that's because earlier in\n> >> the life of the repo we did just do the flat branch layout, but\n> >> decided to make it more structured once that got unwieldy.\n> > \n> > Cough, cough. _What_ did you specify in your .git/config file\n> > regarding the svn structure? Please quote the section.\n> > \n> \n> Erm, sorry.\n> \n> [svn-remote \"svn\"]\n> url = svn://svn..com\n> fetch = trunk:refs/remotes/trunk\n> branches = branches/*:refs/remotes/*\n> tags = tags/*:refs/remotes/tags/*\n> \n> (URL changed in case it annoys my employers)\n> \n> I didn't write this by hand: it was generated by git-svn init.\n> \n\nTry something like this:\n\n[svn-remote \"svn\"]\n\t# trunk\n\tfetch = trunk:refs/remotes/trunk\n\n\t# branches\n\tfetch = branches/category-a/branch_a:refs/remotes/svn/branch_a\n\tfetch = branches/category-a/branch_b:refs/remotes/svn/branch_b\n\tfetch = branches/category-b/branch_c:refs/remotes/svn/branch_c\n\n\t# tags\n\ttags = tags/*:refs/remotes/tags/*\n\n\n(Not sure if wildcards will work here, but I'm sure you could experiment and try\n it out :-)\n\n-Peter\n"},{"id":"52500","messageId":"46DD9DE7.1060004@gmail.com","threadId":"9775","inReplyTo":"20070904174006.GB4538@xp.machine.xx","subject":"Re: git-svn and a nested branches folder","fromName":"Russ Brown","fromEmail":"pickscrape@gmail.com","sentAt":"2007-09-04T18:03:19Z","receivedAt":"2007-09-04T18:03:19Z","isPatch":false,"sender":{"key":"pickscrape@gmail.com","avatar":null},"body":"Peter Baumann wrote:\n> On Tue, Sep 04, 2007 at 10:21:22AM -0500, Russ Brown wrote:\n>> David Kastrup wrote:\n>>> Russ Brown writes:\n>>>\n>>>> David Kastrup wrote:\n>>>>> Russ Brown writes:\n>>>>>\n>>>>>> I'm having some trouble with using git-svn to fetch a repository, and I\n>>>>>> think it's because the repository doesn't store branches as a flat list\n>>>>>> directly under the 'branches' directory.\n>>>>>>\n>>>>>> Basically, we have a structure like this:\n>>>>>>\n>>>>>> |\n>>>>>> +-trunk\n>>>>>> +-tags\n>>>>>> +-branches\n>>>>>> + category-a\n>>>>>> + branch-a\n>>>>>> + branch-b\n>>>>>> + category-b\n>>>>>> + branch-c\n>>>>>> + branch-d\n>>>>>>\n>>>>>> etc. category-a and category-b are simple directories created using svn\n>>>>>> mkdir. The branches are created using svn cp.\n>>>>>>\n>>>>>> It helps us to organise the branches better, but the rationale is\n>>>>>> besides the point. The problem is that git-svn seems to want to\n>>>>>> treat category-a and category-b as branches, which isn't right at\n>>>>>> all. As a result, git-svn seems to skip most (if not all) revisions\n>>>>>> that occur in these directories and creates a lot of entries in\n>>>>>> unhandled.log.\n>>>>> So what did you specify in your .git/config file regarding the svn\n>>>>> structure?\n>>>> I specified the 'branches' directory, but that's because earlier in\n>>>> the life of the repo we did just do the flat branch layout, but\n>>>> decided to make it more structured once that got unwieldy.\n>>> Cough, cough. _What_ did you specify in your .git/config file\n>>> regarding the svn structure? Please quote the section.\n>>>\n>> Erm, sorry.\n>>\n>> [svn-remote \"svn\"]\n>> url = svn://svn..com\n>> fetch = trunk:refs/remotes/trunk\n>> branches = branches/*:refs/remotes/*\n>> tags = tags/*:refs/remotes/tags/*\n>>\n>> (URL changed in case it annoys my employers)\n>>\n>> I didn't write this by hand: it was generated by git-svn init.\n>>\n> \n> Try something like this:\n> \n> [svn-remote \"svn\"]\n> \t# trunk\n> \tfetch = trunk:refs/remotes/trunk\n> \n> \t# branches\n> \tfetch = branches/category-a/branch_a:refs/remotes/svn/branch_a\n> \tfetch = branches/category-a/branch_b:refs/remotes/svn/branch_b\n> \tfetch = branches/category-b/branch_c:refs/remotes/svn/branch_c\n> \n> \t# tags\n> \ttags = tags/*:refs/remotes/tags/*\n> \n> \n> (Not sure if wildcards will work here, but I'm sure you could experiment and try\n> it out :-)\n> \n\nThanks a lot! I'll try it out.\n\nI wonder if I'm going to have to fetch in stages here. i.e. configuring\nthe branches for the original layout, fetching up the point where the\nlayout changed a bit and reconfigure, fetch some more, tweak again etc.\n\n> -Peter\n\n\n-- \n\nRuss\n"},{"id":"52532","messageId":"20070905001513.GA9362@soma","threadId":"9775","inReplyTo":"46DD6EEA.9010304@gmail.com","subject":"Re: git-svn and a nested branches folder","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-09-05T00:15:13Z","receivedAt":"2007-09-05T00:15:13Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Russ Brown wrote:\n> Hi,\n\nHi Russ,\n\n> I'm having some trouble with using git-svn to fetch a repository, and I\n> think it's because the repository doesn't store branches as a flat list\n> directly under the 'branches' directory.\n> \n> Basically, we have a structure like this:\n> \n> |\n> +-trunk\n> +-tags\n> +-branches\n> + category-a\n> + branch-a\n> + branch-b\n> + category-b\n> + branch-c\n> + branch-d\n> \n> etc. category-a and category-b are simple directories created using svn\n> mkdir. The branches are created using svn cp.\n> \n> It helps us to organise the branches better, but the rationale is\n> besides the point. The problem is that git-svn seems to want to treat\n> category-a and category-b as branches, which isn't right at all. As a\n> result, git-svn seems to skip most (if not all) revisions that occur in\n> these directories and creates a lot of entries in unhandled.log.\n\nThis is a known problem with the way git-svn handles branches and tags.\nNested branch (and tags) structures aren't supported with globbing and\nso you can't have more than one branches/tags specification in your\nconfig.\n\n> I've also encountered an index corruption in one of the\n> .git/svn//index files which I think it probably related.\n\nNot sure about that. git-svn should detect and attempt to fix index\ncorruptions (which happened for me since I interrupt git-svn quite\noften when working on it).\n\n> I've had a quick look at the source myself, but perl isn't my strong\n> point. What I think it should do is something like recurse down the tree\n> from the directory given looking for folders that copy from trunk (or\n> some other branch that already exists). That would work perfectly well\n> for the default flat branch storage method as well as the one we use.\n\nThe globbing functionality of branches in git-svn is some of the ugliest\ncode I've ever written in my life. Somehow I got it working for the\nsimple general cases but I've been afraid to touch it for a while...\n\n> The only other problem is in branch naming, which could clash if you\n> only use the outer-most directory name, so I'd suggest something that\n> involves concatenating the folders in the path relative to 'branches' to\n> keep them unique (if git can handle slashes in branch names then all the\n> better).\n\nAs Peter suggested, disable globbing for branches and use explicit\nfetch refspecs for now...\n\n-- \nEric Wong\n"},{"id":"52575","messageId":"46DE7D37.9040905@gmail.com","threadId":"9775","inReplyTo":"20070905001513.GA9362@soma","subject":"Re: git-svn and a nested branches folder","fromName":"Russ Brown","fromEmail":"pickscrape@gmail.com","sentAt":"2007-09-05T09:56:07Z","receivedAt":"2007-09-05T09:56:07Z","isPatch":false,"sender":{"key":"pickscrape@gmail.com","avatar":null},"body":"Eric Wong wrote:\n> Russ Brown wrote:\n>> Hi,\n> \n> Hi Russ,\n> \n>> I'm having some trouble with using git-svn to fetch a repository, and I\n>> think it's because the repository doesn't store branches as a flat list\n>> directly under the 'branches' directory.\n>>\n>> Basically, we have a structure like this:\n>>\n>> |\n>> +-trunk\n>> +-tags\n>> +-branches\n>> + category-a\n>> + branch-a\n>> + branch-b\n>> + category-b\n>> + branch-c\n>> + branch-d\n>>\n>> etc. category-a and category-b are simple directories created using svn\n>> mkdir. The branches are created using svn cp.\n>>\n>> It helps us to organise the branches better, but the rationale is\n>> besides the point. The problem is that git-svn seems to want to treat\n>> category-a and category-b as branches, which isn't right at all. As a\n>> result, git-svn seems to skip most (if not all) revisions that occur in\n>> these directories and creates a lot of entries in unhandled.log.\n> \n> This is a known problem with the way git-svn handles branches and tags.\n> Nested branch (and tags) structures aren't supported with globbing and\n> so you can't have more than one branches/tags specification in your\n> config.\n> \n>> I've also encountered an index corruption in one of the\n>> .git/svn//index files which I think it probably related.\n> \n> Not sure about that. git-svn should detect and attempt to fix index\n> corruptions (which happened for me since I interrupt git-svn quite\n> often when working on it).\n> \n\nI've since trashes that repo and it's not happened again, so it must\nhave been cosmic particles or something. :)\n\n>> I've had a quick look at the source myself, but perl isn't my strong\n>> point. What I think it should do is something like recurse down the tree\n>> from the directory given looking for folders that copy from trunk (or\n>> some other branch that already exists). That would work perfectly well\n>> for the default flat branch storage method as well as the one we use.\n> \n> The globbing functionality of branches in git-svn is some of the ugliest\n> code I've ever written in my life. Somehow I got it working for the\n> simple general cases but I've been afraid to touch it for a while...\n> \n\nYeah, I know what you mean. :) A really nasty thing to get working and\nonce you do you don't want to touch it again. :)\n\n>> The only other problem is in branch naming, which could clash if you\n>> only use the outer-most directory name, so I'd suggest something that\n>> involves concatenating the folders in the path relative to 'branches' to\n>> keep them unique (if git can handle slashes in branch names then all the\n>> better).\n> \n> As Peter suggested, disable globbing for branches and use explicit\n> fetch refspecs for now...\n> \n\nI've actually knocked up a rough script which generates a list of\nrefspec lines for you given a repo URL, trunk reference and branches\ndirectory. It uses svn log -v --xml and pipes it through a couple of\nXSLT templates, and basically looks for all copies that copy from trunk\n(recursively: so it includes branches of branches too). I can post it to\nthe list if you'd find it useful or interesting.\n\nIt's generating output that looks sensible to me, but the results aren't\nquite what I'd expected. I'll paste a sample in here in case there's\nanything obvious someone might spot that I've missed\n\n# This line was generated by git-svn init, and I kept it\nfetch = all/trunk:refs/remotes/trunk\n\n# These lines generated by my tool, dirnames replaced for security reasons:\n\nfetch = branches/folder/projecta:refs/remotes/svn/folder/projecta\nfetch = branches/folder/projectb:refs/remotes/svn/folder/projectb\nfetch = branches/folder/projectc:refs/remotes/svn/folder/projectc\nfetch = branches/folder/projectd:refs/remotes/svn/folder/projectd\nfetch = branches/folder/projecte:refs/remotes/svn/folder/projecte\nfetch = branches/folder/projectf:refs/remotes/svn/folder/projectf\nfetch = branches/folder/projectg:refs/remotes/svn/folder/projectg\n\ngit branch -a doesn't list any of those branches after fetch completes.\nLooking back at the output from fetch, all revisions applied were to trunk.\n\nAnything wrong with those fetch lines?\n\nThanks for your time.\n\n-- \n\nRuss\n"},{"id":"52576","messageId":"20070905100919.GA11074@soma","threadId":"9775","inReplyTo":"46DE7D37.9040905@gmail.com","subject":"Re: git-svn and a nested branches folder","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-09-05T10:09:19Z","receivedAt":"2007-09-05T10:09:19Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Russ Brown wrote:\n> Eric Wong wrote:\n> > Russ Brown wrote:\n> >> Basically, we have a structure like this:\n> >>\n> >> |\n> >> +-trunk\n> >> +-tags\n> >> +-branches\n> >> + category-a\n> >> + branch-a\n> >> + branch-b\n> >> + category-b\n> >> + branch-c\n> >> + branch-d\n\n> >> The only other problem is in branch naming, which could clash if you\n> >> only use the outer-most directory name, so I'd suggest something that\n> >> involves concatenating the folders in the path relative to 'branches' to\n> >> keep them unique (if git can handle slashes in branch names then all the\n> >> better).\n> > \n> > As Peter suggested, disable globbing for branches and use explicit\n> > fetch refspecs for now...\n> > \n> \n> I've actually knocked up a rough script which generates a list of\n> refspec lines for you given a repo URL, trunk reference and branches\n> directory. It uses svn log -v --xml and pipes it through a couple of\n> XSLT templates, and basically looks for all copies that copy from trunk\n> (recursively: so it includes branches of branches too). I can post it to\n> the list if you'd find it useful or interesting.\n> \n> It's generating output that looks sensible to me, but the results aren't\n> quite what I'd expected. I'll paste a sample in here in case there's\n> anything obvious someone might spot that I've missed\n> \n> # This line was generated by git-svn init, and I kept it\n> fetch = all/trunk:refs/remotes/trunk\n> \n> # These lines generated by my tool, dirnames replaced for security reasons:\n> \n> fetch = branches/folder/projecta:refs/remotes/svn/folder/projecta\n> fetch = branches/folder/projectb:refs/remotes/svn/folder/projectb\n> fetch = branches/folder/projectc:refs/remotes/svn/folder/projectc\n> fetch = branches/folder/projectd:refs/remotes/svn/folder/projectd\n> fetch = branches/folder/projecte:refs/remotes/svn/folder/projecte\n> fetch = branches/folder/projectf:refs/remotes/svn/folder/projectf\n> fetch = branches/folder/projectg:refs/remotes/svn/folder/projectg\n> \n> git branch -a doesn't list any of those branches after fetch completes.\n> Looking back at the output from fetch, all revisions applied were to trunk.\n> \n> Anything wrong with those fetch lines?\n\n>From your tree diagram, it seemed that trunk/ and branches/ were at\nthe same depth in your SVN repository. However, in your generated\nfetch lines they all started with \"branches/\" in front, yet your\ntrunk fetch line had \"all/\" in front of trunk, so maybe prefixing\nthe generated ones with \"all/\" helps?\n\n> Thanks for your time.\n\nNo problem.\n\n-- \nEric Wong\n"},{"id":"52577","messageId":"46DE81B5.7090500@gmail.com","threadId":"9775","inReplyTo":"20070905100919.GA11074@soma","subject":"Re: git-svn and a nested branches folder","fromName":"Russ Brown","fromEmail":"pickscrape@gmail.com","sentAt":"2007-09-05T10:15:17Z","receivedAt":"2007-09-05T10:15:17Z","isPatch":false,"sender":{"key":"pickscrape@gmail.com","avatar":null},"body":"Eric Wong wrote:\n> Russ Brown wrote:\n>> Eric Wong wrote:\n>>> Russ Brown wrote:\n>>>> Basically, we have a structure like this:\n>>>>\n>>>> |\n>>>> +-trunk\n>>>> +-tags\n>>>> +-branches\n>>>> + category-a\n>>>> + branch-a\n>>>> + branch-b\n>>>> + category-b\n>>>> + branch-c\n>>>> + branch-d\n> \n>>>> The only other problem is in branch naming, which could clash if you\n>>>> only use the outer-most directory name, so I'd suggest something that\n>>>> involves concatenating the folders in the path relative to 'branches' to\n>>>> keep them unique (if git can handle slashes in branch names then all the\n>>>> better).\n>>> As Peter suggested, disable globbing for branches and use explicit\n>>> fetch refspecs for now...\n>>>\n>> I've actually knocked up a rough script which generates a list of\n>> refspec lines for you given a repo URL, trunk reference and branches\n>> directory. It uses svn log -v --xml and pipes it through a couple of\n>> XSLT templates, and basically looks for all copies that copy from trunk\n>> (recursively: so it includes branches of branches too). I can post it to\n>> the list if you'd find it useful or interesting.\n>>\n>> It's generating output that looks sensible to me, but the results aren't\n>> quite what I'd expected. I'll paste a sample in here in case there's\n>> anything obvious someone might spot that I've missed\n>>\n>> # This line was generated by git-svn init, and I kept it\n>> fetch = all/trunk:refs/remotes/trunk\n>>\n>> # These lines generated by my tool, dirnames replaced for security reasons:\n>>\n>> fetch = branches/folder/projecta:refs/remotes/svn/folder/projecta\n>> fetch = branches/folder/projectb:refs/remotes/svn/folder/projectb\n>> fetch = branches/folder/projectc:refs/remotes/svn/folder/projectc\n>> fetch = branches/folder/projectd:refs/remotes/svn/folder/projectd\n>> fetch = branches/folder/projecte:refs/remotes/svn/folder/projecte\n>> fetch = branches/folder/projectf:refs/remotes/svn/folder/projectf\n>> fetch = branches/folder/projectg:refs/remotes/svn/folder/projectg\n>>\n>> git branch -a doesn't list any of those branches after fetch completes.\n>> Looking back at the output from fetch, all revisions applied were to trunk.\n>>\n>> Anything wrong with those fetch lines?\n> \n> From your tree diagram, it seemed that trunk/ and branches/ were at\n> the same depth in your SVN repository. However, in your generated\n> fetch lines they all started with \"branches/\" in front, yet your\n> trunk fetch line had \"all/\" in front of trunk, so maybe prefixing\n> the generated ones with \"all/\" helps?\n> \n\nAh! I think I know what I've done. I generated the fetch list from the\nsvn repository itself, but ran svn-init against an svk mirror (using\n--use-svm-props). Nicely spotted. :)\n\nThanks again!\n\n>> Thanks for your time.\n> \n> No problem.\n> \n\n\n-- \n\nRuss\n"}]}