On Thu, 22 Dec 2016 13:48:47 +0000, Stefan Sperling wrote: ... > I think this idea is short-sighted. I can imagine this suggestion to cause > major inconvenience if implemented.
I know of a VCS having done exactly this. > 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. Or for use within scripts to communicate with things they invoke indirectly. We use this productively because you cannot easily just have .vcs inside a clearcase view or a temporary tree, so we keep it outside. > Since each .svn dir lives in a separate working copy its path is not a > global system setting. A safer alternative would be to look, when in /home/ak/some/wc, for /home/ak/some/wc/.svn /home/ak/some/.svn.wc /home/ak/.svn.some.wc /home/.svn.ak.some.wc /.svn.home.ak.some.wc or with an envvar SVNDIRS=/home/ak/svndirs /home/ak/some/wc/.svn /home/ak/svndirs/.svn.home/ak/some.wc > 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, incidentallly, is also *much* more complex to implement, beginning with the problem that you can no longer just throw away a working copy and its .svn directory, and ending with two users accessing a WC that will now look into two different places for the .svn dir. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800