Ryan Schmidt wrote:
> On Aug 21, 2008, at 17:46, Steven J. Murdoch wrote:
>
>> 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.
>
> It is definitely a no-no to create a repository within a repository...
> so it wouldn't hurt if svnadmin would detect and warn about, or event
> prevent, this situation.
Agreed. This can lead to a sticky situation. The one question, though, is how
far up the directory structure should svnadmin recurse to determine if the
proposed new repository is in an existing repository? 1 level? 2 levels? All
the way to the root?
-Hyrum
Received on 2008-08-22 17:38:48 CEST