{"thread":{"id":"20751","subject":"git-svn-Cloning repository with complicate nesting","startedAt":"2009-08-27T08:32:55Z","lastAt":"2009-09-03T16:50:24Z","messageCount":4,"participants":["Daniele Segato","Marc Branchaud"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"121853","messageId":"9accb4400908270132vaccc4eegb58e2f0ee8de0797@mail.gmail.com","threadId":"20751","inReplyTo":null,"subject":"git-svn-Cloning repository with complicate nesting","fromName":"Daniele Segato","fromEmail":"daniele.bilug@gmail.com","sentAt":"2009-08-27T08:32:55Z","receivedAt":"2009-08-27T08:32:55Z","isPatch":false,"sender":{"key":"daniele.bilug@gmail.com","avatar":null},"body":"Hi, this is my first message in the list: this may be a newbie\nquestion and my English may not be very good.\n\nI've an SVN repository structured like this:\n\nhttp://<url>/path/to/repo\n    |\n  HEAD\n    |----- root\n    |\n  BRANCHES\n    |----- V1.0\n    |         |----- root\n    |\n    |----- V1.1\n    |         |----- root\n    |\n    |----- V1.2\n    |         |----- root\n    |\n    |----- DEV\n    |         |----- FEATURE1\n    |         |            |----- root\n    |         |\n    |         |----- FEATURE2\n    |         |            |----- root\n    |         |\n    |         |----- FEATURE3\n    |                      |----- root\n    |\n    |----- BUILDS\n              |----- BUILD1\n              |            |----- root\n              |\n              |----- BUILD2\n              |            |----- root\n              |\n              |----- BUILD3\n                           |----- root\n\nthe same for TAGS.\n\nI did this:\n\ngit init\ngit svn init <url>\nvim .git/config\n\n[core]\n\trepositoryformatversion = 0\n\tfilemode = true\n\tbare = false\n\tlogallrefupdates = true\n[svn-remote \"svn\"]\n\turl = <url>\n\tfetch = <url>/HEAD/root:refs/remotes/trunk\n\tbranches = <url>/BRANCHES/*/root:refs/remotes/branches/*\n\tbranches = <url>/BRANCHES/*/*/root:refs/remotes/devel/*\n\ttags = <url>/TAGS/*/root:refs/remotes/tags/*\n\n\ngit svn fetch\n\n\nIt is now cloning the repo (it is a really big repo)\n\n\nIt is my configuration ok for the repository structure?\n\nif from another terminal I execute \"git branch -r\" I get:\n  tags/V1.3.0\n  tags/V1.3.0@3260\n  tags/V1.3.1\n  tags/V1.3.1@3359\n  tags/V1.3.2\n  tags/V1.3.2@4256\n  tags/V1.4.0-COMMUNITY-FINAL\n  tags/V1.4.0-ENTERPRISE-BETA@4241\n  trunk\n  trunk@4475\n\nIt should have already created some branch but I don't see any...\n\nwhat are those @XXXX number for some of those branches?\n\nIs the syntax of the svn-remote configuration correct?\n\nwith this:\nbranches = <url>/BRANCHES/*/*/root:refs/remotes/devel/*\nhow does git choose the name of the branch? (\nrefs/remotes/devel/WHAT_GOES_HERE ? )\n\nI would like it to use the tuple */* of the directory\n\n\nIf the syntax of my configuration is not correct, where can I found a\ndocumentation about it? I couldn't find one.\n\n\nThanks\nRegards,\nDaniele\n"},{"id":"122357","messageId":"4A9FD34A.7020101@xiplink.com","threadId":"20751","inReplyTo":"9accb4400908270132vaccc4eegb58e2f0ee8de0797@mail.gmail.com","subject":"Re: git-svn-Cloning repository with complicate nesting","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2009-09-03T14:31:38Z","receivedAt":"2009-09-03T14:31:38Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"Hi Daniele,\n\nI think you're stuck.  Someone who knows git-svn better than I might be able to figure out a solution (I haven't played with using wildcards in the middle of branches refspecs), but as far as I can tell git-svn can't support your repository's structure.\n\nThe fundamental problem is that the BRANCHES/ hierarchy isn't consistent.  git-svn expects the directories under a 'branches' path to be branch names.  In your case, you can't specify a configuration that covers your whole repository.\n\nThis:\n\n\tbranches = <url>/BRANCHES/DEV/*:refs/remotes/svn/dev/*\n\tbranches = <url>/BRANCHES/BUILDS/*:refs/remotes/svn/builds/*\n\nwill let you track the stuff under BRANCHES/DEV and BRANCHES/BUILDS, but won't let you see the V*.* branches.\n\nThis:\n\n\tbranches = <url>/BRANCHES/*:refs/remotes/svn/*\n\nwill let you see the V*.* branches, but will get confused over the DEV and BUILDS stuff (because it's expecting the layout to be DEV/root and BUILDS/root).\n\nSo I think git-svn would need to be modified to support your situation.\n\nOne possible approach is to make git-svn smart about what it considers a branch's name.  In theory, what you'd like is to just specify\n\n\tbranches = <url>/BRANCHES/*:refs/remotes/svn/*\n\nand have git-svn properly identify all the branches:\n\n\tV1.0\n\tV1.1\n\tV1.2\n\tDEV/FEATURE1\n\tDEV/FEATURE2\n\tDEV/FEATURE3\n\tBUILDS/BUILD1\n\tBUILDS/BUILD2\n\tBUILDS/BUILD3\n\nTo do this, git-svn could track the current 'trunk' directory structure (just the top-level contents of the root should suffice).  Then when it detects a new path under BRANCHES it could search through that path until it finds the same 'trunk' directory structure, and then use the path as the full branch name.\n\nFor example, say a repository's trunk has 3 directories and a file:\n\ttrunk/\n\t\tfoo/...\n\t\tbar/...\n\t\tbaz/...\n\t\treadme.txt\nWhen a commit creates a new branch:\n\tbranches/some/path/\n\t\tfoo/...\n\t\tbar/...\n\t\tbaz/...\n\t\treadme.txt\ngit-svn sees that the commit is to a new path under branches/ and looks through branches/some/ and branches/some/path/ to find the trunk's contents, deciding in this case that 'some/path' is the branch's name.\n\nAnyway, this is just an idea of how things might work.  There are probably some corner-cases that could make this a bit tricky to implement...\n\n\t\tM.\n\n\nDaniele Segato wrote:\n> Hi, this is my first message in the list: this may be a newbie\n> question and my English may not be very good.\n> \n> I've an SVN repository structured like this:\n> \n> http://<url>/path/to/repo\n>     |\n>   HEAD\n>     |----- root\n>     |\n>   BRANCHES\n>     |----- V1.0\n>     |         |----- root\n>     |\n>     |----- V1.1\n>     |         |----- root\n>     |\n>     |----- V1.2\n>     |         |----- root\n>     |\n>     |----- DEV\n>     |         |----- FEATURE1\n>     |         |            |----- root\n>     |         |\n>     |         |----- FEATURE2\n>     |         |            |----- root\n>     |         |\n>     |         |----- FEATURE3\n>     |                      |----- root\n>     |\n>     |----- BUILDS\n>               |----- BUILD1\n>               |            |----- root\n>               |\n>               |----- BUILD2\n>               |            |----- root\n>               |\n>               |----- BUILD3\n>                            |----- root\n> \n> the same for TAGS.\n> \n> I did this:\n> \n> git init\n> git svn init <url>\n> vim .git/config\n> \n> [core]\n> \trepositoryformatversion = 0\n> \tfilemode = true\n> \tbare = false\n> \tlogallrefupdates = true\n> [svn-remote \"svn\"]\n> \turl = <url>\n> \tfetch = <url>/HEAD/root:refs/remotes/trunk\n> \tbranches = <url>/BRANCHES/*/root:refs/remotes/branches/*\n> \tbranches = <url>/BRANCHES/*/*/root:refs/remotes/devel/*\n> \ttags = <url>/TAGS/*/root:refs/remotes/tags/*\n> \n> \n> git svn fetch\n> \n> \n> It is now cloning the repo (it is a really big repo)\n> \n> \n> It is my configuration ok for the repository structure?\n> \n> if from another terminal I execute \"git branch -r\" I get:\n>   tags/V1.3.0\n>   tags/V1.3.0@3260\n>   tags/V1.3.1\n>   tags/V1.3.1@3359\n>   tags/V1.3.2\n>   tags/V1.3.2@4256\n>   tags/V1.4.0-COMMUNITY-FINAL\n>   tags/V1.4.0-ENTERPRISE-BETA@4241\n>   trunk\n>   trunk@4475\n> \n> It should have already created some branch but I don't see any...\n> \n> what are those @XXXX number for some of those branches?\n> \n> Is the syntax of the svn-remote configuration correct?\n> \n> with this:\n> branches = <url>/BRANCHES/*/*/root:refs/remotes/devel/*\n> how does git choose the name of the branch? (\n> refs/remotes/devel/WHAT_GOES_HERE ? )\n> \n> I would like it to use the tuple */* of the directory\n> \n> \n> If the syntax of my configuration is not correct, where can I found a\n> documentation about it? I couldn't find one.\n> \n> \n> Thanks\n> Regards,\n> Daniele\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"122362","messageId":"9accb4400909030917y2e8d4c97tef1320c05d4c4e1c@mail.gmail.com","threadId":"20751","inReplyTo":"4A9FD34A.7020101@xiplink.com","subject":"Re: git-svn-Cloning repository with complicate nesting","fromName":"Daniele Segato","fromEmail":"daniele.bilug@gmail.com","sentAt":"2009-09-03T16:17:07Z","receivedAt":"2009-09-03T16:17:07Z","isPatch":false,"sender":{"key":"daniele.bilug@gmail.com","avatar":null},"body":"On Thu, Sep 3, 2009 at 4:31 PM, Marc Branchaud<marcnarc@xiplink.com> wrote:\n> Hi Daniele,\n\nHi Marc and thank you for your reply.\n\n> I think you're stuck.  Someone who knows git-svn better than I might be able to figure out a solution (I haven't played with using wildcards in the middle of branches refspecs), but as far as I can tell git-svn can't support your repository's structure.\n>\n> The fundamental problem is that the BRANCHES/ hierarchy isn't consistent.  git-svn expects the directories under a 'branches' path to be branch names.  In your case, you can't specify a configuration that covers your whole repository.\n\nyes..\nand developers should be smart enought to keep consistency on their\nown.. unfurtunately they oftern aren't\n\n> So I think git-svn would need to be modified to support your situation.\n\nI'm not feeling that lucky but I would be happy about it. :-)\n\n> One possible approach is to make git-svn smart about what it considers a branch's name.  In theory, what you'd like is to just specify\n\n> To do this, git-svn could track the current 'trunk' directory structure (just the top-level contents of the root should suffice).  Then when it detects a new path under BRANCHES it could search through that path until it finds the same 'trunk' directory structure, and then use the path as the full branch name.\n\n> When a commit creates a new branch:\n\n> git-svn sees that the commit is to a new path under branches/ and looks through branches/some/ and branches/some/path/ to find the trunk's contents, deciding in this case that 'some/path' is the branch's name.\n>\n> Anyway, this is just an idea of how things might work.  There are probably some corner-cases that could make this a bit tricky to implement...\n\nhum...\nIt could be an idea but I don't know how hard could it be to check it:\nhow much deep inside the tree should Git search for branch? what if\nthere are branches that are completely differents?\n\nmay be the user could create and pass a \"branch model\" to git svn to\nmake it able to decide what is a branch and what isn't.\n\nI think there are many options\n\nIn my case It would have worked defining a structure like:\nBRANCHES/*/root -> remote/svn/branch/*\nBRANCHES/*/*/root -> remote/svn/branch/*/*\n\nBut it would be better with something like:\nBRANCHES/\\([^\\/]+\\)/root -> remote/svn/branch/$1\nBRANCHES/\\([^\\/]+\\)/\\([^\\/]+\\)/root -> remote/svn/branch/$1/$2\n\nlike a grouped regex.\n\nevery branch not matching the regex will be skipped..\nonly an idea.. It couln't work in every situation but it would allow a\ngreater degree of freedom in the configuration.\n\nI don't know if Git developers are interested in thinking on some\nfeatures like this.. it sound like an SVN-only hack to me.\n\nRegards,\nDaniele\n"},{"id":"122365","messageId":"4A9FF3D0.9040606@xiplink.com","threadId":"20751","inReplyTo":"9accb4400909030917y2e8d4c97tef1320c05d4c4e1c@mail.gmail.com","subject":"Re: git-svn-Cloning repository with complicate nesting","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2009-09-03T16:50:24Z","receivedAt":"2009-09-03T16:50:24Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"Daniele Segato wrote:\n> \n> hum...\n> It could be an idea but I don't know how hard could it be to check it:\n> how much deep inside the tree should Git search for branch?\n\nWell, as far as it takes.  Actually, the search should be fairly well constrained.  After checking that the entries under a particular path aren't a copy of the trunk, each entry can only represent either a branch that git-svn already knows about, or a new branch.\n\n> what if there are branches that are completely differents?\n\nNot sure what you mean there.  Can you come up with an example of this?\n\n> may be the user could create and pass a \"branch model\" to git svn to\n> make it able to decide what is a branch and what isn't.\n> \n> I think there are many options\n> \n> In my case It would have worked defining a structure like:\n> BRANCHES/*/root -> remote/svn/branch/*\n> BRANCHES/*/*/root -> remote/svn/branch/*/*\n> \n> But it would be better with something like:\n> BRANCHES/\\([^\\/]+\\)/root -> remote/svn/branch/$1\n> BRANCHES/\\([^\\/]+\\)/\\([^\\/]+\\)/root -> remote/svn/branch/$1/$2\n> \n> like a grouped regex.\n> \n> every branch not matching the regex will be skipped..\n> only an idea.. It couln't work in every situation but it would allow a\n> greater degree of freedom in the configuration.\n\nTurning the branch refspecs into true regular expressions sounds like a good idea to me, and would probably be easier to implement than the trunk-detection stuff I proposed.  Though there'd have to be a way to stay compatible with or upgrade the current non-regex refspecs.\n\n> I don't know if Git developers are interested in thinking on some\n> features like this.. it sound like an SVN-only hack to me.\n\nAll of git-svn is already a hack for dealing with SVN.  :)  I'm sure a patch for this would be welcome.\n\n\t\tM.\n"}]}