Branko Čibej wrote on Thu, Dec 22, 2016 at 11:03:27 +0100: > 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.
Allowing to specify the location fo the .svn dir through a --option or envvar does not require sharing .svn dirs amongst different working copies. The only code change that should be needed is a short-circuit codepath in the function that recurses upwards to find the .svn dir.
