Setting $HOME in the testsuite

[Hyrum K Wright <hy...@hyrumwright.org>]

More fallout from my issue #3765 work: I'm investing using ~/.svnrc to
provide default arguments to the commandline client.  In doing so, it
makes loads of sense not to use the a developer's ~/.svnrc when
running the tests.  Since this is found via the svn_user_get_homedir()
function, which uses the $HOME environment variable, we coud easily
redirect that to avoid this conflict.  (It would also allow testing of
this feature.)

I know we provide a standard config directory in the testsuite, but
wouldn't it also be reasonable to create a dummy home directory?
Grepping through the python test suite yield no results for HOME, so I
assume we are currently using the developer's home directory.

-Hyrum

Re: Setting $HOME in the testsuite

[Branko Čibej <br...@xbc.nu>]

On 23.12.2010 01:37, Hyrum K Wright wrote:
> More fallout from my issue #3765 work: I'm investing using ~/.svnrc to
> provide default arguments to the commandline client.  In doing so, it
> makes loads of sense not to use the a developer's ~/.svnrc when
> running the tests.  Since this is found via the svn_user_get_homedir()
> function, which uses the $HOME environment variable, we coud easily
> redirect that to avoid this conflict.  (It would also allow testing of
> this feature.)
>
> I know we provide a standard config directory in the testsuite, but
> wouldn't it also be reasonable to create a dummy home directory?
> Grepping through the python test suite yield no results for HOME, so I
> assume we are currently using the developer's home directory.

You need to add an option to ignore that "svnrc" (wherever it is)
anyway, otherwise there's no safe way to write scripts that work
reliably on different systems. By implication, the command-line parsing
will have to be revisited:

    * parse the command-line
    * if not ignored, parse "svnrc" and set option defaults based on the
      command
    * re-apply options from the actual command line because these should
      (and currently do) override any coming from a config file.

Then just tell the test suite to ignore "svnrc". Problem solved, not
least because $HOME has no real meaning on Windows, AFAICR.

I don't believe you can skip one of the parsing steps (i.e., can't
introduce "svnrc" and /not/ dig deep into command and option resolution
order) and still make that config file useful.

-- Brane

Re: Setting $HOME in the testsuite

[Branko Čibej <br...@xbc.nu>]

On 23.12.2010 06:09, Peter Samuelson wrote:
> And I still think that 90% of end users, maybe 99%, do _not_ think of
> Subversion as a stack of libraries that just happens to also ship some
> command-line wrapper programs as a convenience.  Consequently I think
> they'd prefer the smaller top-level-dotfile footprint of
> ~/.subversion/svnrc, even if we would historically regard it
> as a layering violation.

I agree with that part, not least because there's no concept of
~/.subversion or ~/.svnrc on Windows; we put the subversion config dir
in the user's (or system) profile dir, which is not equivalent to $HOME.
It's much easier for everyone to deal with one set of config file
locations, even on Unix-derived systems.

-- Brane

Re: Setting $HOME in the testsuite

[Peter Samuelson <pe...@p12n.org>]

[Hyrum K Wright]
> Just curious if this suggestion is made in light of the concerns I
> expressed in the other thread.  Namely, that the location of the
> config directory isn't determined until parsing the commandline args,
> at which point it may be too late to introduce the additional args
> obtained through the newly-discovered config file.

Sorry, missed that half of that thread.  I've read it now.

Brane brings up the good point that, regardless of whether svnrc is
sensitive to --config-dir, it will need to be sensitive to --no-rc.
At which point, parsing order of --config-dir is a solved problem.

And I still think that 90% of end users, maybe 99%, do _not_ think of
Subversion as a stack of libraries that just happens to also ship some
command-line wrapper programs as a convenience.  Consequently I think
they'd prefer the smaller top-level-dotfile footprint of
~/.subversion/svnrc, even if we would historically regard it
as a layering violation.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/

Re: Setting $HOME in the testsuite

[Hyrum K Wright <hy...@hyrumwright.org>]

On Wed, Dec 22, 2010 at 9:31 PM, Peter Samuelson <pe...@p12n.org> wrote:
>
> [Hyrum K Wright]
>> More fallout from my issue #3765 work: I'm investing using ~/.svnrc
>> to provide default arguments to the commandline client.  In doing so,
>> it makes loads of sense not to use the a developer's ~/.svnrc when
>> running the tests.
>
> I'd suggest putting svnrc inside ~/.subversion (or --config-dir).  I
> know ~/.subversion is for the library and svnrc is for the command line
> binary, but I think for an end user that's a pretty fine distinction to
> make.  The last thing I need are even more top-level dotfiles in my
> $HOME.
>
> And using --config-dir would make your $HOME question moot.

Just curious if this suggestion is made in light of the concerns I
expressed in the other thread.  Namely, that the location of the
config directory isn't determined until parsing the commandline args,
at which point it may be too late to introduce the additional args
obtained through the newly-discovered config file.

I'm not claiming that ~/.svnrc is the optimal solution, just pointing
out something would would need to be handled if we used
~/.subversion/foo.

-Hyrum

Re: Setting $HOME in the testsuite

[Peter Samuelson <pe...@p12n.org>]

[Hyrum K Wright]
> More fallout from my issue #3765 work: I'm investing using ~/.svnrc
> to provide default arguments to the commandline client.  In doing so,
> it makes loads of sense not to use the a developer's ~/.svnrc when
> running the tests.

I'd suggest putting svnrc inside ~/.subversion (or --config-dir).  I
know ~/.subversion is for the library and svnrc is for the command line
binary, but I think for an end user that's a pretty fine distinction to
make.  The last thing I need are even more top-level dotfiles in my
$HOME.

And using --config-dir would make your $HOME question moot.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/