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.richter_at_trust.cased.de> wrote:
> Am Thu, 10 Feb 2011 14:27:17 -0600
> schrieb Ryan Schmidt <subversion-2011a_at_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.
>
Received on 2011-02-15 16:46:07 CET