I think it's reasonable for Subversion to enforce its "ownership" of the repository directory and not support users creating stuff in it. (Encapsulation is a good thing.) Perhaps the following layout would do what you want:
mkdir project1 svnadmin create project1/repos mkdir project1/projectA svnadmin create project1/projectA/repos mkdir project2 svnadmin create project2/repos etc. That way you have your hierarchy yet you aren't messing with the internal structure of Subversion's repository. So everyone is happy :) -Ed On Fri, Feb 11, 2011 at 4:18 AM, Fabian Richter <fabian.rich...@trust.cased.de> wrote: > Am Thu, 10 Feb 2011 14:27:17 -0600 > schrieb Ryan Schmidt <subversion-20...@ryandesign.com>: > >> >> $ svnadmin create repo1 >> $ svnadmin create repo1/repo2 >> svnadmin: 'repo1/repo2' is a subdirectory of an existing repository >> rooted at 'repo1' $ svnadmin create repo2 >> $ mv repo2 repo1 >> $ ls repo1 >> README.txt db hooks repo2 >> conf format locks >> $ >> >> Et voilà, you have repo2's directory inside repo1's directory. >> > > Yes, this is the only way I would be able to do it, though its a pretty > nasty thing if you have scripts, creating your repositories on the fly. > > Again because noone really understood the problem: I need nested > repositories because without I can not grant granular access rights. > > Eg: I have a redmine project called x and a repository called x. I > have access to that repos and some other dudes. Now I need to create a > new subproject that belongs virtually to x called z. To maintain this > connection I want it to be visible within redmine as a subproject to x. > I also want to grant access to that project to different people than I > granted to x. Still I need to maintain the connection to x and hence > the need of creating subrepositories... > > Funny noone of you mentioned one damn reason why the force option would > be bad. You just said "Its not like we want it to be" but apart from > that, your argumentation is not present. >
