On Thu, Dec 22, 2016 at 11:47:41AM +0000, Daniel Shahaf wrote: > 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.
I think this idea is short-sighted. I can imagine this suggestion to cause major inconvenience if implemented. Inevitably, an environment variable will point to a .svn directory of one working copy but the current working directory will be part of a different working copy. Environment variables are useful for global system settings. Since each .svn dir lives in a separate working copy its path is not a global system setting. I think the use case described would be much better served by implementing support for a shared .svn dir located e.g. in the user's home directory which can then be shared by multiple working copies. This would work without an env var or new option switch. This central .svn dir could always be looked up automatically with a fallback to the current behaviour if the global .svn does not exist. There is no technical reason why this could not be done. It is just a lot of work nobody has time for.
