Major Description
WWhen 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.
Further discussion can be found in this mailing list thread:
http://subversion.tigris.org/servlets/BrowseList?list=users&by=thread&from=674795
http://permalink.gmane.org/gmane.comp.version-control.subversion.user/80857
Original issue reported by sjmurdoch