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.
Received on 2016-12-22 12:50:41 CET