Alberto Bertogli [off-list ref] writes:
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.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
David Kastrup, el 14 de agosto a las 07:45 me escribiste:
Alberto Bertogli [off-list ref] writes:
quoted
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>
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.
--
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.
Leandro Lucarella [off-list ref] writes:
David Kastrup, el 14 de agosto a las 07:45 me escribiste:
quoted
Alberto Bertogli [off-list ref] writes:
quoted
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.
[...]
The patch is for git-svnimport, not git-svn
Oops. In that case, I have no qualified opinion.
--
David Kastrup