On 21.12.2016 17:57, Miller, Hugh wrote: >> What is the problem you are trying to solve? > The context is versioning file sets/trees that are used by other applications > and processes. In this situation, it is nice or imperative to be able to > treat the file set/tree as just the original, but still have it versioned. > This is obtained if the versioning tool in no way alters the original file > tree. The newer treatment of .svn goes most of the way but does not quite do > this. > > Also, just my untutored mania, it seems cleaner, and provides freedom, to > govern the .svn location with an environment variable, since there is nothing > in the concept or nature of .svn that would require it to be located as is > done now.
Well, in theory, there's not. In practice, there's not only one .svn directory; there's one per working copy, and that includes referenced externals. Having only one .svn directory would imply putting data for multiple working copies into the same database. The database schema supports that; the code does not. -- Brane
