Candidate bug: svnadmin should refuse to create nested repositories

When accessing a repository with a nested sub-repository, subversion
behaves very strangely and breaks external tools (e.g. mercurial
convert). It may also cause data loss (or at least cause data to be
difficult to access without manual repository repair).

I think the root failure is that svnadmin will create a nested
sub-repository. I can think of several reasons why this is a bad
thing, and no reasons why it might be desirable. Therefore, I would
like to suggest svnadmin should refuse to create a repository within
an existing repository.

Here is an example set of commands which lead to the bad situation. A
very similar situation occurred on an installation I maintained, and
it was messy to clean up. In the end I had to lose the history, since
merging the long histories of the multiple repositories would have
been a lot of work.
 
 1. $ svn --version
    svn, version 1.4.6 (r28521) compiled Mar 11 2008, 08:26:35
 2. $ svnadmin create /path/to/repo
 3. $ svn mkdir file:///path/to/repo/foo
    Committed revision 1.
 4. $ svnadmin create /path/to/repo/foo
 5. $ svn ls -r1 file:///path/to/repo
    foo/
 6. $ svn ls -r1 file:///path/to/repo/foo
    svn: No such revision 1

The problem occurs because the URL file:///path/to/repo/foo may refer
to two different locations:
 a) Directory foo in the repository at file:///path/to/repo or
 b) Directory / in the repository at file:///path/to/repo/foo

Line 5 indicates and example of subversion doing (a) and line 6 is it
doing (b). If it is possible to create files in one nested repository
which "shadow" the parent repository files, then one version will be
inaccessible, and effectively lost.

I couldn't find a mention of this scenario, in the bug database or
mailing list. If someone else agrees that it is a problem I will
submit an issue tracker entry recommending that svnadmin not create
nested repositories, or at least require a force flag.

Thanks,
Steven.

-- 
w: http://www.cl.cam.ac.uk/users/sjm217/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org