Re: svnadmin create complains about subrepositories

[Ed Price]

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.

Re: svnadmin create complains about subrepositories

[Stefan Sperling]

On Fri, Feb 11, 2011 at 10:10:40PM +0200, Daniel Shahaf wrote:
 Stefan Sperling wrote on Fri, Feb 11, 2011 at 21:10:20 +0100:
  On Fri, Feb 11, 2011 at 07:16:24PM +0200, Daniel Shahaf wrote:
   Stefan Sperling wrote on Thu, Feb 10, 2011 at 16:59:11 +0100:
But I also think that the check for an existing repository should
work within any subdirectory of the repository, not just within the
top-level directory of the repository.

Can you help by filing a DEFECT issue in our issue tracker
(http://subversion.tigris.org/issue-tracker.html) requesting that the
check be expanded to also work within subdirectories of a repository?
   
   Don't.  It's already this way.  Hyrum+I wrote it some time back.
   
   The reason?  Because the URLs would be ambiguous: what should
   % svn info file://$PWD/path/to/dir/trunk | grep -i 'repository 
   root:'
   print?
  
  What has this got to do with running svnadmin create within repos/db
  or repos/hooks?
  
  Maybe you qouted the wrong paragraph and you were referring to
  the ENHANCEMENT I mentioned that would allow creating nested
  repositories? I've since changed my mind.
 
 I was trying to say that nested repositories are blocked (at any
 depth-distance) because any URL referring to the deeper repository could
 also refer to the parent/ancestor repository, and there's no way to
 resolve the ambiguity.

Ah, OK. You're saying that nested repositories will never work because
it's not clear whether parts of a URL refer to a filesystem path to a
nested repository, or to a versioned path within the parent repository
of the nested repository.  That's a good explanation for why people have
been asking about how the nested repository would be accessed.

I am, however, talking about something else in the part of my email
you've quoted. I said:
 But I also think that the check for an existing repository should
  work within any subdirectory of the repository, not just within the
  top-level directory of the repository.

What I am saying is that the following should error out:
$ svnadmin create repos
$ cd repos/db
$ svnadmin create repos
$

just like this already does:
$ svnadmin create repos
$ cd repos
$ svnadmin create repos
subversion/svnadmin/main.c:600: (apr_err=165002)
subversion/libsvn_repos/repos.c:1393: (apr_err=165002)
svnadmin: E165002: 'repos' is a subdirectory of an existing repository 
rooted at '.'

Re: svnadmin create complains about subrepositories

[Daniel Shahaf]

Stefan Sperling wrote on Sat, Feb 12, 2011 at 13:59:16 +0100:
 What I am saying is that the following should error out:
   $ svnadmin create repos
   $ cd repos/db
   $ svnadmin create repos
   $

Oh, sorry, Stefan.  I missed that it doesn't error when the cwd is
repos/db.  (When the cwd is elsewhere it does error.)

The fix is to convert PATH (a dirent) to an absolute path before passing
it in svn_repos_create() to svn_repos_find_root_path().  If someone
could remind me what the APR wrapper for os.path.abspath() is, I'll
commit a fix.

Thanks.

Daniel

 just like this already does:
   $ svnadmin create repos
   $ cd repos
   $ svnadmin create repos
   subversion/svnadmin/main.c:600: (apr_err=165002)
   subversion/libsvn_repos/repos.c:1393: (apr_err=165002)
   svnadmin: E165002: 'repos' is a subdirectory of an existing repository 
 rooted at '.'

Re: svnadmin create complains about subrepositories

[Stefan Sperling]

On Sat, Feb 12, 2011 at 05:31:50PM +0200, Daniel Shahaf wrote:
 Stefan Sperling wrote on Sat, Feb 12, 2011 at 13:59:16 +0100:
  What I am saying is that the following should error out:
  $ svnadmin create repos
  $ cd repos/db
  $ svnadmin create repos
  $
 
 Oh, sorry, Stefan.  I missed that it doesn't error when the cwd is
 repos/db.  (When the cwd is elsewhere it does error.)

My (admittedly light) testing shows that the check only works in the
top-level directory of a repos. E.g. repos/hook has the same problem
as does repos/db in my example. So does repos/db/revs etc.

 The fix is to convert PATH (a dirent) to an absolute path before passing
 it in svn_repos_create() to svn_repos_find_root_path().  If someone
 could remind me what the APR wrapper for os.path.abspath() is, I'll
 commit a fix.

Ah, thanks for the hint! This seems to fix it:

[[[
* subversion/libsvn_repos/repos.c
  (svn_repos-create): Prevent repository creation within all subdirectories
   of a repository, not just within the top-level one.
   While here, show absolute paths in error messages, and send a less
   confusing error message when the user tries to create a repository
   at the location of an existing repository.
]]]


Index: subversion/libsvn_repos/repos.c
===
--- subversion/libsvn_repos/repos.c (revision 1070107)
+++ subversion/libsvn_repos/repos.c (working copy)
@@ -1369,6 +1369,7 @@ svn_repos_create(svn_repos_t **repos_p,
   svn_repos_t *repos;
   svn_error_t *err;
   const char *root_path;
+  const char *local_abspath;
 
   /* Allocate a repository object, filling in the format we will create. */
   repos = create_svn_repos_t(path, pool);
@@ -1388,13 +1389,21 @@ svn_repos_create(svn_repos_t **repos_p,
 repos-fs_type = DEFAULT_FS_TYPE;
 
   /* Don't create a repository inside another repository. */
-  root_path = svn_repos_find_root_path(path, pool);
+  SVN_ERR(svn_dirent_get_absolute(local_abspath, path, pool));
+  root_path = svn_repos_find_root_path(local_abspath, pool);
   if (root_path != NULL)
-return svn_error_createf(SVN_ERR_REPOS_BAD_ARGS, NULL, _('%s' is a 
-  subdirectory of an existing repository rooted 
-  at '%s'),
-  svn_dirent_local_style(path, pool),
-  svn_dirent_local_style(root_path, pool));
+{
+  if (strcmp(root_path, local_abspath) == 0)
+return svn_error_createf(SVN_ERR_REPOS_BAD_ARGS, NULL,
+ _('%s' is an existing repository),
+ svn_dirent_local_style(root_path, pool));
+  else
+return svn_error_createf(SVN_ERR_REPOS_BAD_ARGS, NULL,
+ _('%s' is a subdirectory of an existing 
+   repository  rooted at '%s'),
+ svn_dirent_local_style(local_abspath, pool),
+ svn_dirent_local_style(root_path, pool));
+}
 
   /* Create the various files and subdirectories for the repository. */
   SVN_ERR_W(create_repos_structure(repos, path, fs_config, pool),

Re: svnadmin create complains about subrepositories

[Fabian Richter]

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.txtdb  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.


signature.asc
Description: PGP signature

Re: svnadmin create complains about subrepositories

[Thorsten Schöning]

Guten Tag Fabian Richter,
am Freitag, 11. Februar 2011 um 10:18 schrieben Sie:

 I also want to grant access to that project to different people than I
 granted to x.

authz-file and it's directory dependant permissions doesn't fit your
needs?

 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.

The reasons was mentioned: It's unlikely that the devs want to
maintain such a setup. If they provide a switch to enforce such a
setup, it becomes some kind of an official way to create a setup
nobody really seem to want and whoever used the switch to create
such a repository layout will blame the devs if they do something
in future which is incompatible with this layout, because one just
used the --force option.

Especially if you are using scripts to create your layout, it should
be fairly simple to add a directory move.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
 
Telefon: Potsdam: 0331-743881-0
E-Mail:  tschoen...@am-soft.de
Web: http://www.am-soft.de

AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow

RE: svnadmin create complains about subrepositories

[Cooke, Mark]

 -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
  confformat  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

RE: svnadmin create complains about subrepositories

[Bob Archer]

 On Thursday 10 February 2011, Stefan Sperling wrote:
  On Thu, Feb 10, 2011 at 07:02:18PM +0100, Fabian Richter wrote:
   Am Thu, 10 Feb 2011 11:24:09 -0600
   schrieb Ryan Schmidt subversion-20...@ryandesign.com:
On Feb 10, 2011, at 09:59, Stefan Sperling wrote:
 and can you please add an --force switch to
 still being able to create Repositories within the path of
 another?

 That's a reasonable request, I think. Not a usual use case
 but why
 not?
   
Really? What possible reason could exist for doing this? :)
 
  I have no idea, to be honest. But then again I'm not going to
 guess.
  Maybe someone can present a good use case for this? Dunno.
 
 The only reason I'm aware of is that you want to make browsing
 easier when you
 have multiple repositories, as there is otherwise no way to do
 that. The idea
 is that you have a parent FS-dir that contains the parent repo. The
 parent
 repo FS-contains the child repos. Further, it has repo-directories
 for each
 child repository, too. Since SVN tries to walk the FS-path as far
 as possible
 for locating the repository. Therefore, a svn ls parent will show
 the
 repo-content of the parent's root but a svn ls parent/child-x
 will not show
 the repo-content of the parent's child-x subdir but show the root
 of the
 parent/child-x repository.
 
 In that light, I support the suggested --force option for people
 that
 really, really need it.

If I have a project that has child sub-project I really really want them to be 
in the same repository. Actually, I put all my projects in the same repository 
so I can browser them in some repository browser like T-SVN of ViewVC. We 
have multiple repositories but they are for different product groups that work 
on projects that have no relationship to each other what so ever. Even those 
could be in the same repository but seeing how path based auth slows things 
down it seemed to make more sense to give each product group their own repo.

BOb

RE: svnadmin create complains about subrepositories

[Bob Archer]

 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
  confformat  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.

Have you brought this up on the redmine support or users list? It seems to me 
that more than one person would be using nested projects in RedMine and since 
nested repositories in svn is an anti-pattern I expect there is a better way to 
do this... or you are not understanding RedMine's sub-projects... or there is a 
deficiency in redminds security that doesn't allow you to set different 
permissions to a nested subprojects in a single repository. 

Perhaps redmine doesn't require the nested projects to actually point to nested 
repositories? 

BOb

Re: svnadmin create complains about subrepositories

[Daniel Shahaf]

Stefan Sperling wrote on Thu, Feb 10, 2011 at 16:59:11 +0100:
 But I also think that the check for an existing repository should
 work within any subdirectory of the repository, not just within the
 top-level directory of the repository.
 
 Can you help by filing a DEFECT issue in our issue tracker
 (http://subversion.tigris.org/issue-tracker.html) requesting that the
 check be expanded to also work within subdirectories of a repository?

Don't.  It's already this way.  Hyrum+I wrote it some time back.

The reason?  Because the URLs would be ambiguous: what should
% svn info file://$PWD/path/to/dir/trunk | grep -i 'repository root:'
print?

Re: svnadmin create complains about subrepositories

[Daniel Shahaf]

Daniel Shahaf wrote on Fri, Feb 11, 2011 at 19:16:24 +0200:
 The reason?  Because the URLs would be ambiguous: what should
 % svn info file://$PWD/path/to/dir/trunk | grep -i 'repository root:'
 print?
(forgot to say that both $PWD and $PWD/path/to are repositories)

Re: svnadmin create complains about subrepositories

[Stefan Sperling]

On Fri, Feb 11, 2011 at 11:26:36AM -0500, Bob Archer wrote:
 Perhaps redmine doesn't require the nested projects to actually point to 
 nested repositories? 
 

It doesn't.

In redmine, each subproject has some repository location associated with it.
For Subversion, that's a URL. So it can be in its own repos or some path
within an existing repository shared with other projects.

I would say that the project grouping in redmine is a *UI feature*.
It has nothing to do with how things are stored on the server.
The storage doesn't need to mirror what you see in the UI.

Re: svnadmin create complains about subrepositories

[Stefan Sperling]

On Fri, Feb 11, 2011 at 07:16:24PM +0200, Daniel Shahaf wrote:
 Stefan Sperling wrote on Thu, Feb 10, 2011 at 16:59:11 +0100:
  But I also think that the check for an existing repository should
  work within any subdirectory of the repository, not just within the
  top-level directory of the repository.
  
  Can you help by filing a DEFECT issue in our issue tracker
  (http://subversion.tigris.org/issue-tracker.html) requesting that the
  check be expanded to also work within subdirectories of a repository?
 
 Don't.  It's already this way.  Hyrum+I wrote it some time back.
 
 The reason?  Because the URLs would be ambiguous: what should
 % svn info file://$PWD/path/to/dir/trunk | grep -i 'repository root:'
 print?

What has this got to do with running svnadmin create within repos/db
or repos/hooks?

Maybe you qouted the wrong paragraph and you were referring to
the ENHANCEMENT I mentioned that would allow creating nested
repositories? I've since changed my mind.

Re: svnadmin create complains about subrepositories

[Daniel Shahaf]

Stefan Sperling wrote on Fri, Feb 11, 2011 at 21:10:20 +0100:
 On Fri, Feb 11, 2011 at 07:16:24PM +0200, Daniel Shahaf wrote:
  Stefan Sperling wrote on Thu, Feb 10, 2011 at 16:59:11 +0100:
   But I also think that the check for an existing repository should
   work within any subdirectory of the repository, not just within the
   top-level directory of the repository.
   
   Can you help by filing a DEFECT issue in our issue tracker
   (http://subversion.tigris.org/issue-tracker.html) requesting that the
   check be expanded to also work within subdirectories of a repository?
  
  Don't.  It's already this way.  Hyrum+I wrote it some time back.
  
  The reason?  Because the URLs would be ambiguous: what should
  % svn info file://$PWD/path/to/dir/trunk | grep -i 'repository 
  root:'
  print?
 
 What has this got to do with running svnadmin create within repos/db
 or repos/hooks?
 
 Maybe you qouted the wrong paragraph and you were referring to
 the ENHANCEMENT I mentioned that would allow creating nested
 repositories? I've since changed my mind.

I was trying to say that nested repositories are blocked (at any
depth-distance) because any URL referring to the deeper repository could
also refer to the parent/ancestor repository, and there's no way to
resolve the ambiguity.

Re: svnadmin create complains about subrepositories

[Les Mikesell]

On 2/11/2011 10:22 AM, Bob Archer wrote:


If I have a project that has child sub-project I really really want them to be in the 
same repository. Actually, I put all my projects in the same repository so I can browser 
them in some repository browser like T-SVN of ViewVC.


Viewvc is perfectly happy to let you browse multiple repositories that 
are created in the same root directory.


--
  Les Mikesell
   lesmikes...@gmail.com

RE: svnadmin create complains about subrepositories

[Bob Archer]

 I just recently upgraded to svn 1.6.12 and had to realize
 
 svnadmin create
 
 wont let me create Repositories inside directories where have
 already
 repositories been created.
 
 Why is that a feature and can you please add an --force switch to
 still being able to create Repositories within the path of another?

I guess my question would be why do you want to do that... and I would also 
say DON'T do that. 

Bob

Re: svnadmin create complains about subrepositories

[Stefan Sperling]

On Thu, Feb 10, 2011 at 04:15:16PM +0100, Fabian Richter wrote:
 Hi,
 
 I just recently upgraded to svn 1.6.12 and had to realize

Which version did you upgrade from?

As far as I can tell this behaviour has existed for some time,
since at least 1.5. Did you upgrade from an earlier version which
had different behaviour?

I've checked current trunk and 1.5, and the behaviour is the
same in both. The check only works within the top-level directory
of the repository, though:

$ ls
README.txt   conf/db/  format   hooks/   locks/
$ svnadmin create repos
subversion/libsvn_repos/repos.c:1203: (apr_err=165002)
svnadmin: 'repos' is a subdirectory of an existing repository rooted at ''
$ cd db/   
$ svnadmin create repos 
$ cd ..
$ cd hooks/
$ svnadmin create repos
$ 

 
 svnadmin create
 
 wont let me create Repositories inside directories where have already 
 repositories been created.
 
 Why is that a feature

Because it's likely a mistake.
Nesting repositories is not what many people want.

 and can you please add an --force switch to
 still being able to create Repositories within the path of another?

That's a reasonable request, I think. Not a usual use case but why not?

But I also think that the check for an existing repository should
work within any subdirectory of the repository, not just within the
top-level directory of the repository.

Can you help by filing a DEFECT issue in our issue tracker
(http://subversion.tigris.org/issue-tracker.html) requesting that the
check be expanded to also work within subdirectories of a repository?
And an ENHANCEMENT issue that allows the check to be overridden by a
new command line option (named something like '--allow-nested-repositories'
since we don't use --force anymore because it's not always clear what's
being forced). You can use this link to refer to this thread from the
issue as required by our bug filing guidelines:
http://svn.haxx.se/users/archive-2011-02/0162.shtml

Maybe you'd even be willing to try to send a patch for either of
these items?

Thanks,
Stefan

Re: svnadmin create complains about subrepositories

[Ryan Schmidt]

On Feb 10, 2011, at 09:59, Stefan Sperling wrote:

 and can you please add an --force switch to
 still being able to create Repositories within the path of another?
 
 That's a reasonable request, I think. Not a usual use case but why not?

Really? What possible reason could exist for doing this? :)

Re: svnadmin create complains about subrepositories

[Fabian Richter]

Am Thu, 10 Feb 2011 11:24:09 -0600
schrieb Ryan Schmidt subversion-20...@ryandesign.com:

 
 On Feb 10, 2011, at 09:59, Stefan Sperling wrote:
 
  and can you please add an --force switch to
  still being able to create Repositories within the path of another?
  
  That's a reasonable request, I think. Not a usual use case but why
  not?
 
 Really? What possible reason could exist for doing this? :)
 

We are using Redmine as a projectmanagement Tool and there projects can
have subprojects. This hierarchy we also want in the file system level
so we can see from the url of the repos which category it belongs to.

@Stefan: I have no idea what the former Version was, but I upgraded
from debian Lenny to squeeze so it was probably 1.5.1.

Would it hurt to add a force switch? I mean its at the users risk isnt
it?

Fabian

Re: svnadmin create complains about subrepositories

[David Chapman]

On 2/10/2011 10:19 AM, Fabian Richter wrote:

Am Thu, 10 Feb 2011 13:07:27 -0500
schrieb Bob Archerbob.arc...@amsi.com:


I expect that this all happens inside the repository. A repository's
contents can have whatever folder layout you want. However, the
repositories themselves on the server each need to be peers. You
can't nest repos nor should you need to.


To be frank: I dont see why I am not able to create nested repos or
what you mean that they need to be peers...

You say a repo folder can have the content i need it to have. I need
them to have other repos. To be sure we are talking about the same
thing:

/repos1
/repos1/repos2
/repos1/repos3

something like that. And the comparison to mysql DB doesnt make sense,
because in a dbms I am able to deklare multiple databases for the same
server or root dir, thats what is apparently not possible for svn...




In Subversion, the subdirectories are stored within a single 
repository.  You are not creating a repository that holds a single 
directory of files; a repository is a versioned file system that can 
have subdirectories within it.  One repository directory = multiple 
controlled file directories in a virtual, versioned file system.


Rather than nested repositories as you suggest, the usual way of doing 
things is to have subprojects within a single repository:


/repos
/repos/subproject1
/repos/subproject2
/repos/subproject3

These are all virtual directories, and you can check out or traverse 
them separately even if they are managed by a single repository and its 
server.


Otherwise you would have multiple repositories stored in directories 
which are peers of each other (cf. SVNParentPath in httpd.conf), and 
your workspace setup script would check out the necessary directories 
from the individual repositories.


Storing repository files (which are a kind of database, BTW) inside a 
directory that hold files for another repository is very likely to cause 
problems someday.  The repository files are managed by the Subversion 
software, and it has certain implicit assumptions about what will be 
there.  It's not expecting arbitrary data in arbitrary places.  Support 
of this feature would greatly constrain the developers and I wouldn't 
expect them to like it (I know I wouldn't, if I were a Subversion 
developer).


--
David Chapman dcchap...@acm.org
Chapman Consulting -- San Jose, CA

Re: svnadmin create complains about subrepositories

[Kris Deugau]

Fabian Richter wrote:

To be frank: I dont see why I am not able to create nested repos


A Subversion repository, from the point of view of the filesystem it 
lives on, is intended to be (mostly) a black box that you interact with 
through the SVN repository access layer you've configured.



or
what you mean that they need to be peers...


You can have a set of repositories side-by-side like so:

/path/to/repo1
/path/to/repo2
/path/to/repo3

You can't put another repository inside another, *at the same filesystem 
level*, like so:


/path/to/repo1
/path/to/repo1/repo2
/path/to/repo1/repo3

You *can*, if you really want, add a filesystem location containing a 
SVN repository as content to an existing repository...  although how 
you'd access it usefully is another matter.



You say a repo folder can have the content i need it to have. I need
them to have other repos. To be sure we are talking about the same
thing:

/repos1
/repos1/repos2
/repos1/repos3


Can you expand on why you really need to do this?  Why can't you use 
folders in a single repository, or just leave /repos1 as a regular 
filesystem directory, that contains repositories?


To ask things a bit differently, does arbitrary content under the URL 
that leads to /repos1 need to be version-controlled (eg, /repos1/file1), 
or is all the version-controlled content one layer deeper 
(/repos1/repos2/file1)?



something like that. And the comparison to mysql DB doesnt make sense,
because in a dbms I am able to deklare multiple databases for the same
server or root dir, thats what is apparently not possible for svn...


Well, when you create a MySQL database, the tabledefs at least all go 
into /path/to/mysqldir/database2 - you can't put them in 
/path/to/mysqldir/database1/database2.


Subversion is pretty much the same, except you as administrator have 
somewhat more control of the filesystem location of each repository; 
it's perfectly possible (if inadvisable unless you need to isolate repo 
groups) to put a couple of repositories under /path/to/repgroup1, and 
another group under /another/place/repogroup2, and a lonely one off by 
itself in /some/other/repo.


-kgd

Re: svnadmin create complains about subrepositories

[Ryan Schmidt]

On Feb 10, 2011, at 12:55, Kris Deugau wrote:

 something like that. And the comparison to mysql DB doesnt make sense,
 because in a dbms I am able to deklare multiple databases for the same
 server or root dir, thats what is apparently not possible for svn...
 
 Well, when you create a MySQL database, the tabledefs at least all go into 
 /path/to/mysqldir/database2 - you can't put them in 
 /path/to/mysqldir/database1/database2.

Exactly. Exactly! 

Re: svnadmin create complains about subrepositories

[Ryan Schmidt]

On Feb 10, 2011, at 09:15, Fabian Richter wrote:

 Why is that a feature and can you please add an --force switch to
 still being able to create Repositories within the path of another?

I should add: this check was added to Subversion to prevent people from doing 
things that make no sense.

If you believe you know better than Subversion (and I continue to think you do 
not in this case) then it is of course trivial to bypass this check:

$ 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
confformat  locks
$

Et voilà, you have repo2's directory inside repo1's directory.

So no --force switch or modification of the Subversion source code is necessary 
to accomplish this questionable goal.

Re: svnadmin create complains about subrepositories

[Stefan Sperling]

On Thu, Feb 10, 2011 at 07:02:18PM +0100, Fabian Richter wrote:
 Am Thu, 10 Feb 2011 11:24:09 -0600
 schrieb Ryan Schmidt subversion-20...@ryandesign.com:
  On Feb 10, 2011, at 09:59, Stefan Sperling wrote:
  
   and can you please add an --force switch to
   still being able to create Repositories within the path of another?
   
   That's a reasonable request, I think. Not a usual use case but why
   not?
  
  Really? What possible reason could exist for doing this? :)

I have no idea, to be honest. But then again I'm not going to guess.
Maybe someone can present a good use case for this? Dunno.

 We are using Redmine as a projectmanagement Tool and there projects can
 have subprojects. This hierarchy we also want in the file system level
 so we can see from the url of the repos which category it belongs to.

I would recommend against doing this because it's usually not
done this way. If you do this you might run into various problems.
Especially if you're ever going to use backup scripts or other repository
management tools that exist -- they might fail in some way.

You should put your repositories into a flat hierarchy.
But that does not prevent you from naming them in accordance with
the hierarchy you see in redmine:

 project1
 project1-subproject1
 project1-subproject2
 project1-subproject2-subproject1
 project2
 ...  etc.

Basically, use dashes instead of slashes.
You can also put repositories for different top-level projects into
separate directories if a single flat hierarchy becomes too cumbersome:

 project1-repositories/ -- a normal directory
 project1  -- a repository
 project1-subproject1  -- a repository
 project1-subproject2  -- a repository
 project1-subproject2-subproject1  -- a repository
 project2-repositories/ -- a normal directory
 project2 -- a repository
 ...  etc.

 @Stefan: I have no idea what the former Version was, but I upgraded
 from debian Lenny to squeeze so it was probably 1.5.1.

Then the behaviour isn't new. I thought you were implying that
what you were trying to do was working with an older version?

 Would it hurt to add a force switch? I mean its at the users risk isnt
 it?

Let's add it only if someone comes up with a good reason for having it.

Thanks,
Stefan

Re: svnadmin create complains about subrepositories

[Ulrich Eckhardt]

On Thursday 10 February 2011, Stefan Sperling wrote:
 On Thu, Feb 10, 2011 at 07:02:18PM +0100, Fabian Richter wrote:
  Am Thu, 10 Feb 2011 11:24:09 -0600
  schrieb Ryan Schmidt subversion-20...@ryandesign.com:
   On Feb 10, 2011, at 09:59, Stefan Sperling wrote:
and can you please add an --force switch to
still being able to create Repositories within the path of another?
   
That's a reasonable request, I think. Not a usual use case but why
not?
  
   Really? What possible reason could exist for doing this? :)

 I have no idea, to be honest. But then again I'm not going to guess.
 Maybe someone can present a good use case for this? Dunno.

The only reason I'm aware of is that you want to make browsing easier when you 
have multiple repositories, as there is otherwise no way to do that. The idea 
is that you have a parent FS-dir that contains the parent repo. The parent 
repo FS-contains the child repos. Further, it has repo-directories for each 
child repository, too. Since SVN tries to walk the FS-path as far as possible 
for locating the repository. Therefore, a svn ls parent will show the 
repo-content of the parent's root but a svn ls parent/child-x will not show 
the repo-content of the parent's child-x subdir but show the root of the 
parent/child-x repository.

In that light, I support the suggested --force option for people that 
really, really need it.

Uli

-- 
ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html
FAQ: http://subversion.apache.org/faq.html
Docs: http://svnbook.red-bean.com/


**
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
Visit our website at http://www.dominolaser.com/
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**