On 2/10/2011 10:19 AM, Fabian Richter wrote:
Am Thu, 10 Feb 2011 13:07:27 -0500
schrieb Bob Archer<bob.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

Reply via email to