You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Andreas Stieger <An...@gmx.de> on 2016/12/21 09:48:55 UTC
Re: environment variable for location of the .svn directory ?
Hello Hugh,
> Is there an environment variable that can be used
> to specify the location of the .svn directory ?
The only method to alter the .svn path (that I am aware of) is the the SVN_ASP_DOT_NET_HACK
http://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html#svn.basic.in-action.wc
> If not, is this planned for a future version ?
What is the problem you are trying to solve?
Andreas
Re: environment variable for location of the .svn directory ?
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Dec 22, 2016 at 01:52:01PM +0100, Olaf van der Spek wrote:
> On Thu, Dec 22, 2016 at 1:48 PM, Stefan Sperling <st...@elego.de> wrote:
> > 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.
>
> How'd the link between the wc and the global .svn store work? The link
> might get broken on moves.
>
> And what if multiple users share one working copy?
Depends on design and implementation details. There are no definite answers.
As Branko pointed out, the 1.7+ WC DB schema was designed with a
global .svn directory in mind. The rest remains to be built on top
and there are of course many open questions such as yours.
Re: environment variable for location of the .svn directory ?
Posted by Olaf van der Spek <ml...@vdspek.org>.
On Thu, Dec 22, 2016 at 1:48 PM, Stefan Sperling <st...@elego.de> wrote:
> 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.
How'd the link between the wc and the global .svn store work? The link
might get broken on moves.
And what if multiple users share one working copy?
--
Olaf
Re: environment variable for location of the .svn directory ?
Posted by Daniel Shahaf <da...@apache.org>.
Olaf van der Spek wrote on Sun, Dec 25, 2016 at 09:59:44 +0100:
> Aren't you covered if you search * instead of . ? AFAIK * excludes dot
> files too.
That excludes _all_ dot files, not just .svn, and doesn't ignore .svn
dirs in nested working copies (such as externals).
I mentioned hidesvn(1) upthread which has none of these drawbacks.
Re: environment variable for location of the .svn directory ?
Posted by Olaf van der Spek <ml...@vdspek.org>.
On Sun, Dec 25, 2016 at 12:06 AM, Andreas Krey <a....@gmx.de> wrote:
> On Fri, 23 Dec 2016 13:22:03 +0000, Olaf van der Spek wrote:
> ...
>> > (modulo externals). Having .svn outside the worktree isn't
>> > relevant for me; my gripe with .svn is that the pristine
>> > copies aren't compressed and thus generate matches in
>> > 'find | xargs grep' (in the nonexistence of 'svn grep').
>>
>> Don't find or grep have options to ignore dot / hidden files?
>
> Sure they have. But you'd need to teach a dozen tools
> this trick instead of letting one place hide it better.
Aren't you covered if you search * instead of . ? AFAIK * excludes dot
files too.
--
Olaf
Re: environment variable for location of the .svn directory ?
Posted by Andreas Krey <a....@gmx.de>.
On Fri, 23 Dec 2016 13:22:03 +0000, Olaf van der Spek wrote:
...
> > (modulo externals). Having .svn outside the worktree isn't
> > relevant for me; my gripe with .svn is that the pristine
> > copies aren't compressed and thus generate matches in
> > 'find | xargs grep' (in the nonexistence of 'svn grep').
>
> Don't find or grep have options to ignore dot / hidden files?
Sure they have. But you'd need to teach a dozen tools
this trick instead of letting one place hide it better.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: environment variable for location of the .svn directory ?
Posted by Olaf van der Spek <ml...@vdspek.org>.
On Fri, Dec 23, 2016 at 11:56 AM, Andreas Krey <a....@gmx.de> wrote:
> On Fri, 23 Dec 2016 09:30:45 +0000, Stefan Sperling wrote:
> ...
>> Well, at the time the wc-ng effort was started, a centralized .svn was
>> one of the design goals. That's why the DB schema is the way it is.
>
> See, I thought, wc-ng was done, with the single .svn directory
> (modulo externals). Having .svn outside the worktree isn't
> relevant for me; my gripe with .svn is that the pristine
> copies aren't compressed and thus generate matches in
> 'find | xargs grep' (in the nonexistence of 'svn grep').
Don't find or grep have options to ignore dot / hidden files?
--
Olaf
Re: environment variable for location of the .svn directory ?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Andreas Krey wrote on Fri, Dec 23, 2016 at 11:56:40 +0100:
> On Fri, 23 Dec 2016 09:30:45 +0000, Stefan Sperling wrote:
> ...
> > Well, at the time the wc-ng effort was started, a centralized .svn was
> > one of the design goals. That's why the DB schema is the way it is.
>
> See, I thought, wc-ng was done, with the single .svn directory
> (modulo externals).
That was another design goal. wc-ng *already uses* one .svn dir per
working copy (modulo externals), and the schema *supports* one .svn for
multiple working copies (even of different repositories).
> Having .svn outside the worktree isn't
> relevant for me; my gripe with .svn is that the pristine
> copies aren't compressed and thus generate matches in
> 'find | xargs grep' (in the nonexistence of 'svn grep').
Some greps accept a �--exclude='*.svn-base'� option.
There's a tool called 'hidesvn' which uses LD_PRELOAD so you can do
�hidesvn grep -R foo� and it won't recurse into .svn dirs.
(You could alias grep to one of the above solutions so hidesvn or
--exclude are always used, they're both harmless when not in a working
copy.)
ag(1) and friends ignore .svn by default.
Cheers,
Daniel
Re: environment variable for location of the .svn directory ?
Posted by Andreas Krey <a....@gmx.de>.
On Fri, 23 Dec 2016 09:30:45 +0000, Stefan Sperling wrote:
...
> Well, at the time the wc-ng effort was started, a centralized .svn was
> one of the design goals. That's why the DB schema is the way it is.
See, I thought, wc-ng was done, with the single .svn directory
(modulo externals). Having .svn outside the worktree isn't
relevant for me; my gripe with .svn is that the pristine
copies aren't compressed and thus generate matches in
'find | xargs grep' (in the nonexistence of 'svn grep').
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: environment variable for location of the .svn directory ?
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Dec 23, 2016 at 08:06:38AM +0100, Andreas Krey wrote:
> On Thu, 22 Dec 2016 13:48:47 +0000, Stefan Sperling wrote:
> > 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 agree that such a scheme would be neat and predictable. Thank you!
Having the env var point to a parent dir of .svn dirs seems like a
good enough solution to the problem I see with the original proposal.
> > 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.
Well, at the time the wc-ng effort was started, a centralized .svn was
one of the design goals. That's why the DB schema is the way it is.
It's just too bad that work on these grand ideas has not been finished.
I am probably being a bit cynical because, to be honest, I don't expect
anyone will pick up and finish the task at this point.
Re: environment variable for location of the .svn directory ?
Posted by Andreas Krey <a....@gmx.de>.
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
Re: environment variable for location of the .svn directory ?
Posted by Stefan Sperling <st...@elego.de>.
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.
Re: environment variable for location of the .svn directory ?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Branko \u010cibej 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.
Re: environment variable for location of the .svn directory ?
Posted by Branko Čibej <br...@apache.org>.
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
RE: Re: environment variable for location of the .svn directory ?
Posted by "Miller, Hugh" <Hu...@chevron.com>.
> -----Original Message-----
> From: Branko Čibej [mailto:brane@apache.org]
> Sent: Wednesday, December 21, 2016 5:30 AM
> To: users@subversion.apache.org
> Subject: [**EXTERNAL**] Re: environment variable for location of the .svn
> directory ?
>
> On 21.12.2016 10:48, Andreas Stieger wrote:
> > Hello Hugh,
> >
> >> Is there an environment variable that can be used
> >> to specify the location of the .svn directory ?
> > The only method to alter the .svn path (that I am aware of) is the the
> SVN_ASP_DOT_NET_HACK
> > http://svnbook.red-bean.com/nightly/en/svn.basic.in-
> action.html#svn.basic.in-action.wc
>
> And to be quite candid, I have no idea if that even works any more ...
> the code is there, but I'm not aware of anyone having tested Subversion
> releases with that flag set. As far as I understand it's not very
> relevant any more (or, rather, that ASP.Net is not relevant).
>
> -- Brane
Thanks.
Andreas asked
> 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.
Re: environment variable for location of the .svn directory ?
Posted by Branko Čibej <br...@apache.org>.
On 21.12.2016 10:48, Andreas Stieger wrote:
> Hello Hugh,
>
>> Is there an environment variable that can be used
>> to specify the location of the .svn directory ?
> The only method to alter the .svn path (that I am aware of) is the the SVN_ASP_DOT_NET_HACK
> http://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html#svn.basic.in-action.wc
And to be quite candid, I have no idea if that even works any more ...
the code is there, but I'm not aware of anyone having tested Subversion
releases with that flag set. As far as I understand it's not very
relevant any more (or, rather, that ASP.Net is not relevant).
-- Brane