[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Bug: Incorrect tree structure on nested repository access

From: Stefan Kueng <tortoisesvn_at_gmail.com>
Date: Thu, 04 Dec 2008 18:54:07 +0100

altern_at_bigmir.net wrote:
>> This setup is not allowed. I've explained this in length before on
>> this list (even though the one who was doing it refused to accept
>> any explanation):
>
> That was me :)
>
>> The repository folder is private, you must not ever mess around
>> inside that folder yourself.
>
>> For example, in your setup above: what would have happened if
>> Subversion would require a folder named "PROJECT" itself one day
>> for storing additional data?
>
> I don't understand why such strictness is required. Is it hard to
> allocate special folder inside the structure of the repository which
> will contain subrepositories? Even if there is no special folder
> defined for this purposes, I always thought it is my business to
> track how should I name folders and whether they are overlap existing
> svn-repo folders. Is this just a matter of compatibility with future
> versions?

It's not possible to allow users to create custom folders/files inside a
repository folder. Once that would be done, Subversion could never
change the structure of such a repository folder ever again - any change
could break existing user-folders/files.

>> Also: you won't be able to create repositories inside an existing
>> repository anymore with Subversion 1.6 - the devs added an explicit
>> check for that so it won't work anymore.
>
> So, as I see, TortoiseSVN is based totally upon subversion and its
> development perspective, which is reasonable. But if I don't agree
> with such idea of subrepositories prohibition, should I convince svn
> developers to change their development plan for 1.6 version and then
> return here to ask for the bug fixing? :) What if 1.7 will allow
> subrepository creation? Will TortoiseSVN contain such functionality
> then? Possibly yes, but I don't have time to wait. I need both merge
> tracking and subrepository functionality. One of the possible
> solution is to use version of TortoiseSVN 1.5 which doesn't have this
> silly bug. Do you know which is it? It seems to me that it always
> existed in 1.5 branch.

You're asking for the wrong thing here. What you really want is to be
able to browse for repositories, which is what you somehow got working
by messing with the internals.
You should ask for a feature like SVNParentPath for apache based svn
repositories to get implemented for svnserve repositories.

*that* would be something a lot of users will want too, and you'll get
support from other users and maybe even some developers for that
feature. Getting any support for your 'feature' to nest repositories
will have no chance at all.

Stefan

-- 
       ___
  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=979745
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].

Received on 2008-12-04 18:54:26 CET

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.