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
> 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.
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-08-22 00:57:08 CEST