> -----Original Message----- > From: Fabian Richter [mailto:fabian.rich...@trust.cased.de] > Sent: 11 February 2011 09:18 > To: users@subversion.apache.org > Subject: Re: svnadmin create complains about subrepositories > > 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.
I personally think what you are trying to do is pretty nasty. > Again because noone really understood the problem: I need nested > repositories because without I can not grant granular access rights. Have you read the subversion book and in particular the parts about path based authorisation? http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html Perhaps noone understood because you asked how to _do_ something specific (which people are cautioning you against) without asking how you can achieve what you _need_ in a way that subversion is designed for and supports? Having said that... > 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... I think you can do all that by creating your (sub)hierarchy within the 'x' repository and using path based authorisation. The most specific path is used for auth so subproject 'z' can have its own auth which overrides that given to 'x'. Unless this conflicts some specific requirement(s) of RedMine that you have not mentioned? What source control does RedMine normally work with? Perhaps you would be better off using that? > 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. One IMHO very good argument was mentioned and you ignored it: you would not dream of messing around inside the file-system location of e.g. PostgreSQL database data files yet that is exactly what you are proposing to do with the subversion system. Are you proposing only to use File:\\ repo access? As also mentioned, implementing what you are asking for may cause unnecessary implementation constraints for the project in the future by implicitly supporting a possibly unique use case? Finally I am wondering: how are you proposing to provide access to the repositories? I shudder to think of the sort of apache config that would be required to serve a repo from inside another repos folder... Subversion supports paths inside repositories and grouping of repos using ParentPaths, all with authorisation mechanisms that satisfy most existing users. ~ mark c
