Allow git-svnimport to take "" as the trunk directory.
PATCH 1/1 Allow git-svnimport to take "" as the trunk directory.
Some repositories started with the trunk in "/" and then moved it to the standard "trunk/" location.
On these repositories, the correct thing would be to call git-svnimport -T "", but because of the way the options are handled, it uses the default "trunk" instead of the given empty string. This patch fixes that behaviour.
Reported by Leandro Lucarella <[email protected]>.
---
While the same could be done for tags and branches, I don't think it makes much sense.
git-svnimport.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
git-svnimport.perl +1 -1
@@ -49,7 +49,7 @@ getopts("A:b:C:dDFhiI:l:mM:o:rs:t:T:SP:R:uv") or usage(); usage if $opt_h; my $tag_name = $opt_t || "tags"; -my $trunk_name = $opt_T || "trunk"; +my $trunk_name = defined $opt_T ? $opt_T : "trunk"; my $branch_name = $opt_b || "branches"; my $project_name = $opt_P || ""; $project_name = "/" . $project_name if ($project_name);
Signature · 1 line
1.5.3.rc4.67.gf9286-dirty
Quoted 5 lines · Alberto Bertogli
Some repositories started with the trunk in "/" and then moved it to the standard "trunk/" location.
On these repositories, the correct thing would be to call git-svnimport -T "",
I would not call that the best solution: it makes the bad decision from the past impact useful work in the future. I very much like git having a good toplevel directory structure.
There are two approaches possible: one is to version the mapping trunk/tags/branches. Another would be if one could tell git-svn where to stick stuff that does not sort into trunk/tags/branches. Incidentally, I've seen repositories that have something like a "support" or "vendor" directory, too.
Signature · 1 line
David Kastrup, Kriemhildstr. 15, 44793 Bochum
David Kastrup, el 14 de agosto a las 07:45 me escribiste:
Quoted 11 lines
Quoted 5 lines · Alberto Bertogli
Some repositories started with the trunk in "/" and then moved it to the standard "trunk/" location.
On these repositories, the correct thing would be to call git-svnimport -T "",
I would not call that the best solution: it makes the bad decision from the past impact useful work in the future. I very much like git having a good toplevel directory structure.
Besides the example of a mutating trunk directory, I have repositories where there is only trunk (in "/" directory) and it never changes. Without this patch, I can't even import that kind of repositories.
With repositories with a mutating trunk directory, I used the options -s and -l to incrementally import the repository. For example:
$ git svnimport -l 100 -T '' <repo> and then $ git svnimport -s 101 -T 'trunk' <repo>
Quoted 5 lines
There are two approaches possible: one is to version the mapping trunk/tags/branches. Another would be if one could tell git-svn where to stick stuff that does not sort into trunk/tags/branches. Incidentally, I've seen repositories that have something like a "support" or "vendor" directory, too.
The patch is for git-svnimport, not git-svn (but maybe git-svn has the same problem). Anyways, a way to map trunk/tags/branches to different directories in different versions would be great, but is a different problem than -T not supporting an empty string.
Signature · 6 lines
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ .------------------------------------------------------------------------, \ GPG: 5F5A8D05 // F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05 / '--------------------------------------------------------------------' Como un rinoceronte que lleva un pájaro en el lomo, yo te alimento, no te veo ni te toco.
Quoted 16 lines · Leandro Lucarella
David Kastrup, el 14 de agosto a las 07:45 me escribiste:
Quoted 11 lines
Quoted 5 lines · Alberto Bertogli
Some repositories started with the trunk in "/" and then moved it to the standard "trunk/" location.
On these repositories, the correct thing would be to call git-svnimport -T "",
I would not call that the best solution: it makes the bad decision from the past impact useful work in the future. I very much like git having a good toplevel directory structure.
Besides the example of a mutating trunk directory, I have repositories where there is only trunk (in "/" directory) and it never changes. Without this patch, I can't even import that kind of repositories.
[...]
Quoted 1 line
The patch is for git-svnimport, not git-svn
Oops. In that case, I have no qualified opinion.
Signature · 1 line
David Kastrup