You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Alan Barrett <ap...@cequrux.com> on 2010/12/23 14:54:27 UTC
--no-config-dir option?
Is there a way to prevent svn from creating a $HOME/.subversion
directory? I know how to make it put the directory in a different
location using --config-dir=/wherever, but I want to avoid creating
it entirely. I can't find an option like "--no-config-dir" or
"--config-dir=none".
I have discovered an ugly workaround: If I set
--configdir=/nonexistent/nonexistent (giving the name of a directory
that does not exist, and whose parent also does not exist), then the
absence of the parent directory means that svn will be unable to create
the child directory.
--apb (Alan Barrett)
Re: --no-config-dir option?
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Alan Barrett,
am Donnerstag, 23. Dezember 2010 um 19:20 schrieben Sie:
> I have to register for an account before I can file an issue? Sorry, I
> prefer not to do that for issues where I have a simple workaround.
Self solving issues are always the best. ;-)
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
Telefon: Potsdam: 0331-743881-0
E-Mail: tschoening@am-soft.de
Web: http://www.am-soft.de
AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
Re: --no-config-dir option?
Posted by Alan Barrett <ap...@cequrux.com>.
On Thu, 23 Dec 2010, Stefan Sperling wrote:
> You could [do this or that]
Sure, I can easily make svn create the .subversion directory elsewhere,
in a number of ways, but I don't want to have it at all.
> That said, I don't see an issue with adding the option you're asking for.
> It is a reasonable request, and people might need it in situations
> where they cannot easily work around such issues.
> If you'd like to add an enhancement request issue in the tracker
> please go ahead.
I have to register for an account before I can file an issue? Sorry, I
prefer not to do that for issues where I have a simple workaround. If I
could file issues anonymously, or after solving a captcha, or via email,
or even using an openid login, then I would be more likely to do so.
--apb (Alan Barrett)
Re: --no-config-dir option?
Posted by Les Mikesell <le...@gmail.com>.
On 12/23/2010 11:37 AM, Stefan Sperling wrote:
>
>> Seems like it should fit in an error handler somewhere. Let the
>> write fail in the uncommon case and fix things up only when needed.
>
> That still means checking for this error in many places and retry.
> We have no way to jump back down to where the error was thrown,
> other than calling the error-throwing function again. If you catch
> the error at a high level this means you'd effectively have to restart
> the entire operation (like, say, "svn merge", which may or may not write
> to files and properties in the WC). So you need to catch it as early
> as possible. This means you'll have to catch it in many places.
Maybe it would have had to be designed in from the start.
> Maybe there really is a good way of doing what you'd like to do,
> but I don't see how. You could try to have a look into the code
> yourself to see if you can find a way to do it. I suppose it also
> depends on what you would call a "write" operation in this context.
> Does creating temporary files count, for example?
That would depend on whether they have to be in $HOME/.subversion or
not. Other programs generally use $TMPDIR for scratch space but it is
always dangerous to change an existing program's behavior.
--
Les Mikesell
lesmikesell@gmail.com
Re: --no-config-dir option?
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Dec 23, 2010 at 10:56:17AM -0600, Les Mikesell wrote:
> On 12/23/2010 10:24 AM, Stefan Sperling wrote:
> >
> >>If you don't need to write/modify something there, why should it be
> >>created if it doesn't already exist? Can't you defer the decision
> >>to create until you need a write?
> >
> >That would mean going into the code of each operation within
> >libsvn_client and sprinkle calls to the config creation code
> >depending on what the operation is going to do.
>
> Seems like it should fit in an error handler somewhere. Let the
> write fail in the uncommon case and fix things up only when needed.
That still means checking for this error in many places and retry.
We have no way to jump back down to where the error was thrown,
other than calling the error-throwing function again. If you catch
the error at a high level this means you'd effectively have to restart
the entire operation (like, say, "svn merge", which may or may not write
to files and properties in the WC). So you need to catch it as early
as possible. This means you'll have to catch it in many places.
One place where you could put this (in theory) is a write lock being
obtained on a WC. But this causes a bit of a layering problem,
because client config stuff shouldn't be handled within the working
copy library.
Maybe there really is a good way of doing what you'd like to do,
but I don't see how. You could try to have a look into the code
yourself to see if you can find a way to do it. I suppose it also
depends on what you would call a "write" operation in this context.
Does creating temporary files count, for example?
Stefan
Re: --no-config-dir option?
Posted by Les Mikesell <le...@gmail.com>.
On 12/23/2010 10:24 AM, Stefan Sperling wrote:
>
>> If you don't need to write/modify something there, why should it be
>> created if it doesn't already exist? Can't you defer the decision
>> to create until you need a write?
>
> That would mean going into the code of each operation within
> libsvn_client and sprinkle calls to the config creation code
> depending on what the operation is going to do.
Seems like it should fit in an error handler somewhere. Let the write
fail in the uncommon case and fix things up only when needed. I'd
actually expect that there would be a lot of cases where your only svn
use is one run to grab some remote source and there would be no need to
clutter HOME directories with default gunk for that.
--
Les Mikesell
lesmikesell@gmail.com
Re: --no-config-dir option?
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Dec 23, 2010 at 10:09:23AM -0600, Les Mikesell wrote:
> On 12/23/2010 9:56 AM, Stefan Sperling wrote:
> >
> >
> >Yes, every svn subcommand creates it, and it has been pointed out before
> >that this might not be necessary.
> >However, I'm wondering if it's even possible to come up with a good
> > split between subcommands that should create it and ones that shouldn't.
>
> If you don't need to write/modify something there, why should it be
> created if it doesn't already exist? Can't you defer the decision
> to create until you need a write?
That would mean going into the code of each operation within
libsvn_client and sprinkle calls to the config creation code
depending on what the operation is going to do.
I don't think that's worth the bother. There are enough special cases as is.
And most people need the config or they don't care if it gets created.
So I think having a simple option to turn config creation on startup off
is a better solution. However, the implementation of this option would
probably still have to intialize config related data structures to default
values if the config isn't created, as code down the road might depend
on this.
For reference, here is the call that creates the configuration files,
from subversion/svn/main.c, with an informative comment that shows
that this has been an open question for some time:
/* ### This really belongs in libsvn_client. The trouble is,
there's no one place there to run it from, no
svn_client_init(). We'd have to add it to all the public
functions that a client might call. It's unmaintainable to do
initialization from within libsvn_client itself, but it seems
burdensome to demand that all clients call svn_client_init()
before calling any other libsvn_client function... On the other
hand, the alternative is effectively to demand that they call
svn_config_ensure() instead, so maybe we should have a generic
init function anyway. Thoughts? */
err = svn_config_ensure(opt_state.config_dir, pool);
if (err)
return svn_cmdline_handle_exit_error(err, pool, "svn: ");
Re: --no-config-dir option?
Posted by Les Mikesell <le...@gmail.com>.
On 12/23/2010 9:56 AM, Stefan Sperling wrote:
>
>
> Yes, every svn subcommand creates it, and it has been pointed out before
> that this might not be necessary.
> However, I'm wondering if it's even possible to come up with a good
> split between subcommands that should create it and ones that shouldn't.
If you don't need to write/modify something there, why should it be
created if it doesn't already exist? Can't you defer the decision to
create until you need a write?
--
Les Mikesell
lesmikesell@gmail.com
Re: --no-config-dir option?
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Dec 23, 2010 at 05:34:09PM +0200, Alan Barrett wrote:
> On Thu, 23 Dec 2010, Stefan Sperling wrote:
> > I don't think there is an official way to prevent the config dir from
> > being created. I'd be interested to know why you need this. What is
> > your use case?
>
> The event that made me notice the problem was cron job owned by root,
> whose command was something like "su serviceuser -c 'svn update
> /path/to/dir'". Think of updating a working copy that contains the
> files used by a web server. The svn update command runs in a context
> where $HOME is root's home directory, and serviceuser is not even
> allowed to write there, and might not even be allowed to read, so I got
> an error or warning (I forget which, and the details change according to
> the permissions).
>
> You ask why I need to avoid creating a .subversion directory, and I
> suppose that I don't absolutely need to avoid creating it, but I also
> don't need *to* create it (it won't contain any useful information), and
> I don't want the clutter.
You could pass the -l option to su so that the homedir of the service
user is used.
Another way to do this is to start the cronjob from the serviceuser
account, by editing that user's crontab instead of root's crontab
(e.g. "crontab -e -u serviceuser" might do the trick).
That said, I don't see an issue with adding the option you're asking for.
It is a reasonable request, and people might need it in situations
where they cannot easily work around such issues.
If you'd like to add an enhancement request issue in the tracker
please go ahead.
> Another annoying issue is that commands that one would expect to be
> read-only (such as "svn status" or "svn info") also create the config
> directory.
Yes, every svn subcommand creates it, and it has been pointed out before
that this might not be necessary.
However, I'm wondering if it's even possible to come up with a good
split between subcommands that should create it and ones that shouldn't.
Re: --no-config-dir option?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Alan Barrett wrote on Thu, Dec 23, 2010 at 17:34:09 +0200:
> On Thu, 23 Dec 2010, Stefan Sperling wrote:
> > I don't think there is an official way to prevent the config dir from
> > being created. I'd be interested to know why you need this. What is
> > your use case?
>
> The event that made me notice the problem was cron job owned by root,
> whose command was something like "su serviceuser -c 'svn update
> /path/to/dir'". Think of updating a working copy that contains the
And if you undefine $HOME?
sudo -u serviceuser env -u HOME svn update /path/to/dir
> files used by a web server. The svn update command runs in a context
> where $HOME is root's home directory, and serviceuser is not even
> allowed to write there, and might not even be allowed to read, so I got
> an error or warning (I forget which, and the details change according to
> the permissions).
>
> You ask why I need to avoid creating a .subversion directory, and I
> suppose that I don't absolutely need to avoid creating it, but I also
> don't need *to* create it (it won't contain any useful information), and
> I don't want the clutter.
>
> Another annoying issue is that commands that one would expect to be
> read-only (such as "svn status" or "svn info") also create the config
> directory.
>
> --apb (Alan Barrett)
Re: --no-config-dir option?
Posted by Alan Barrett <ap...@cequrux.com>.
On Thu, 23 Dec 2010, Stefan Sperling wrote:
> I don't think there is an official way to prevent the config dir from
> being created. I'd be interested to know why you need this. What is
> your use case?
The event that made me notice the problem was cron job owned by root,
whose command was something like "su serviceuser -c 'svn update
/path/to/dir'". Think of updating a working copy that contains the
files used by a web server. The svn update command runs in a context
where $HOME is root's home directory, and serviceuser is not even
allowed to write there, and might not even be allowed to read, so I got
an error or warning (I forget which, and the details change according to
the permissions).
You ask why I need to avoid creating a .subversion directory, and I
suppose that I don't absolutely need to avoid creating it, but I also
don't need *to* create it (it won't contain any useful information), and
I don't want the clutter.
Another annoying issue is that commands that one would expect to be
read-only (such as "svn status" or "svn info") also create the config
directory.
--apb (Alan Barrett)
Re: --no-config-dir option?
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Dec 23, 2010 at 04:54:27PM +0200, Alan Barrett wrote:
> Is there a way to prevent svn from creating a $HOME/.subversion
> directory? I know how to make it put the directory in a different
> location using --config-dir=/wherever, but I want to avoid creating
> it entirely. I can't find an option like "--no-config-dir" or
> "--config-dir=none".
>
> I have discovered an ugly workaround: If I set
> --configdir=/nonexistent/nonexistent (giving the name of a directory
> that does not exist, and whose parent also does not exist), then the
> absence of the parent directory means that svn will be unable to create
> the child directory.
I don't think there is an official way to prevent the config dir from being
created. I'd be interested to know why you need this. What is your use case?
Stefan
Re: --no-config-dir option?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Dec 23, 2010, at 09:16, Eric Hudish wrote:
> See:
> <http://svnbook.red-bean.com/en/1.1/ch07.html#svn-ch-7-sect-1>
Let's not refer people to the old Subversion 1.1 book anymore. The link to the current version of that page (currently for Subversion 1.6) is:
http://svnbook.red-bean.com/nightly/en/svn.advanced.confarea.html
Re: --no-config-dir option?
Posted by Eric Hudish <er...@gmail.com>.
On Thu, 2010-12-23 at 16:54 +0200, Alan Barrett wrote:
> Is there a way to prevent svn from creating a $HOME/.subversion
> directory? I know how to make it put the directory in a different
> location using --config-dir=/wherever, but I want to avoid creating
> it entirely. I can't find an option like "--no-config-dir" or
> "--config-dir=none".
>
> I have discovered an ugly workaround: If I set
> --configdir=/nonexistent/nonexistent (giving the name of a directory
> that does not exist, and whose parent also does not exist), then the
> absence of the parent directory means that svn will be unable to create
> the child directory.
>
See:
<http://svnbook.red-bean.com/en/1.1/ch07.html#svn-ch-7-sect-1>
Quote:
Note that the system-wide configuration area does not alone
dictate mandatory policy—the settings in the per-user
configuration area override those in the system-wide one, and
command-line arguments supplied to the svn program have the
final word on behavior.
...
Registry-based configuration options are parsed before their
file-based counterparts, so are overridden by values found in
the configuration files. In other words, configuration priority
is granted in the following order on a Windows system:
Command-line options
The per-user INI files
The per-user Registry values
The system-wide INI files
The system-wide Registry values
I don't think there's a way to 'override' this because the whole purpose
is to help the user on whatever platform they may be using.
*My* suggestion (if you're bound and determined to accomplish this)
would be to create a link for $HOME/.subversion which points to a
non-existent location. That would essentially provide you the same
functionality as your arg:
--configdir=/nonexistent/nonexistent
--
Eric M. Hudish
"Free for only $99.99!"