You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@wandisco.com> on 2011/03/08 14:46:23 UTC
Re: svn commit: r1079008 - /subversion/trunk/subversion/svnadmin/main.c
stefan2@apache.org writes:
> Author: stefan2
> Date: Mon Mar 7 22:57:04 2011
> New Revision: 1079008
>
> URL: http://svn.apache.org/viewvc?rev=1079008&view=rev
> Log:
> Set FSFS cache default size to 16 MB. This is the same default as
> for everybody else, namely the server processes. Thus, it should
> be reasonable value on the same machines.
16MB may be "reasonable" for normal usage but it still has a significant
effect on the testsuite. The testsuite is an unusual access pattern, it
runs thousands of commands on small repositories. Using a 1MB cache I
can run the testsuite for ra_local/FSFS in 10m15s, with 16MB cache that
increases to 12m30s, a 20% increase. There is a similar increase when
testing ra_svn/FSFS using the default Linux svnserve (a threaded
svnserve has a shared cache so isn't affected).
svnserve and svnadmin both have a -M option, was there any discussion
about using a single letter option for this feature? This could be used
by the testuite to restrict the cache size, but for ra_local/FSFS
testing there is no way to restrict the svn client.
Should we add the -M option to the svn client?
Should we make it configurable via .subversion/config instead or as well?
If svnadmin gets configured by .subversion/config should we remove the
command line option?
--
Philip
Re: svn commit: r1079008 - /subversion/trunk/subversion/svnadmin/main.c
Posted by Stefan Fuhrmann <eq...@web.de>.
On 08.03.2011 15:01, Stefan Sperling wrote:
> On Tue, Mar 08, 2011 at 01:46:23PM +0000, Philip Martin wrote:
>> stefan2@apache.org writes:
>>
>>> Author: stefan2
>>> Date: Mon Mar 7 22:57:04 2011
>>> New Revision: 1079008
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1079008&view=rev
>>> Log:
>>> Set FSFS cache default size to 16 MB. This is the same default as
>>> for everybody else, namely the server processes. Thus, it should
>>> be reasonable value on the same machines.
>> 16MB may be "reasonable" for normal usage but it still has a significant
>> effect on the testsuite. The testsuite is an unusual access pattern, it
>> runs thousands of commands on small repositories. Using a 1MB cache I
>> can run the testsuite for ra_local/FSFS in 10m15s, with 16MB cache that
>> increases to 12m30s, a 20% increase. There is a similar increase when
>> testing ra_svn/FSFS using the default Linux svnserve (a threaded
>> svnserve has a shared cache so isn't affected).
>>
>> svnserve and svnadmin both have a -M option, was there any discussion
>> about using a single letter option for this feature? This could be used
>> by the testuite to restrict the cache size, but for ra_local/FSFS
>> testing there is no way to restrict the svn client.
> Shouldn't the cache be off by default?
In http://svn.haxx.se/dev/archive-2011-01/0468.shtml,
it was suggested that we should keep it enabled for
the time being to weed out the issues that we may
find asap.
So, I would suggest to keep the code active to an
early beta stage to maximize exposure and then to
make -M0 the default for the release.
> We have precedence for other features like this that are strictly opt-in,
> e.g. memcached support in FSFS. I don't think we should assume that the
> new cache code is perfect and enable it by default on any repository for
> any 1.7 server. The feature has not had any exposure in the real world yet.
memcached is slightly different here as it requires
some per-repository configuration to find the servers.
I usually can't work out of the box (unless you assume
a cache server being running on localhost).
> So I think it would be better if the cache was off by default, and must be
> enabled in a configuration file. I suppose svnserve and mod_dav_svn
> configuration files would be the best location for this, because the
> purpose of the cache seems to be to speed up server operation.
> An 'svn' process has a short lifetime so the benefit of this cache
> seems dubious in that situation. I don't see any reason to even provide
> a way to turn it on there.
"svn praise" over ra_local may be the only operation
that actually benefits from fulltext or txdelta caching.
Everything else gets cached anyways.
-- Stefan^2.
RE: svn commit: r1079008 - /subversion/trunk/subversion/svnadmin/main.c
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Ivan Zhakov [mailto:ivan@visualsvn.com]
> Sent: dinsdag 8 maart 2011 15:08
> To: Philip Martin; dev@subversion.apache.org
> Cc: Stefan Sperling
> Subject: Re: svn commit: r1079008 -
> /subversion/trunk/subversion/svnadmin/main.c
>
> On Tue, Mar 8, 2011 at 17:01, Stefan Sperling <st...@elego.de> wrote:
> > On Tue, Mar 08, 2011 at 01:46:23PM +0000, Philip Martin wrote:
> >> stefan2@apache.org writes:
> >>
> >> > Author: stefan2
> >> > Date: Mon Mar 7 22:57:04 2011
> >> > New Revision: 1079008
> >> >
> >> > URL: http://svn.apache.org/viewvc?rev=1079008&view=rev
> >> > Log:
> >> > Set FSFS cache default size to 16 MB. This is the same default as
> >> > for everybody else, namely the server processes. Thus, it should
> >> > be reasonable value on the same machines.
<snip>
> > Shouldn't the cache be off by default?
> >
> > We have precedence for other features like this that are strictly opt-in,
> > e.g. memcached support in FSFS. I don't think we should assume that the
> > new cache code is perfect and enable it by default on any repository for
> > any 1.7 server. The feature has not had any exposure in the real world yet.
> >
> > So I think it would be better if the cache was off by default, and must be
> > enabled in a configuration file. I suppose svnserve and mod_dav_svn
> > configuration files would be the best location for this, because the
> > purpose of the cache seems to be to speed up server operation.
> > An 'svn' process has a short lifetime so the benefit of this cache
> > seems dubious in that situation. I don't see any reason to even provide
> > a way to turn it on there.
> >
> +1!
+1
Bert
Re: svn commit: r1079008 - /subversion/trunk/subversion/svnadmin/main.c
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Tue, Mar 8, 2011 at 17:01, Stefan Sperling <st...@elego.de> wrote:
> On Tue, Mar 08, 2011 at 01:46:23PM +0000, Philip Martin wrote:
>> stefan2@apache.org writes:
>>
>> > Author: stefan2
>> > Date: Mon Mar 7 22:57:04 2011
>> > New Revision: 1079008
>> >
>> > URL: http://svn.apache.org/viewvc?rev=1079008&view=rev
>> > Log:
>> > Set FSFS cache default size to 16 MB. This is the same default as
>> > for everybody else, namely the server processes. Thus, it should
>> > be reasonable value on the same machines.
>>
>> 16MB may be "reasonable" for normal usage but it still has a significant
>> effect on the testsuite. The testsuite is an unusual access pattern, it
>> runs thousands of commands on small repositories. Using a 1MB cache I
>> can run the testsuite for ra_local/FSFS in 10m15s, with 16MB cache that
>> increases to 12m30s, a 20% increase. There is a similar increase when
>> testing ra_svn/FSFS using the default Linux svnserve (a threaded
>> svnserve has a shared cache so isn't affected).
>>
>> svnserve and svnadmin both have a -M option, was there any discussion
>> about using a single letter option for this feature? This could be used
>> by the testuite to restrict the cache size, but for ra_local/FSFS
>> testing there is no way to restrict the svn client.
>
> Shouldn't the cache be off by default?
>
> We have precedence for other features like this that are strictly opt-in,
> e.g. memcached support in FSFS. I don't think we should assume that the
> new cache code is perfect and enable it by default on any repository for
> any 1.7 server. The feature has not had any exposure in the real world yet.
>
> So I think it would be better if the cache was off by default, and must be
> enabled in a configuration file. I suppose svnserve and mod_dav_svn
> configuration files would be the best location for this, because the
> purpose of the cache seems to be to speed up server operation.
> An 'svn' process has a short lifetime so the benefit of this cache
> seems dubious in that situation. I don't see any reason to even provide
> a way to turn it on there.
>
+1!
--
Ivan Zhakov
Re: svn commit: r1079008 - /subversion/trunk/subversion/svnadmin/main.c
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Mar 8, 2011 at 11:14, Stefan Sperling <st...@elego.de> wrote:
>...
> Fair enough, but it should still be opt-in.
> We could add a config directive in ~/.subversion/config.
> If it turns out to be beneficial, users will enable it.
> However, since ra_local is used mostly for testing I don't expect this
> to be used much in practice. Our test suite might benefit.
I would like to just snip this suggestion in the bud right now.
Add options to the config file is *NASTY*. It completely disconnects
the operation of the command from the inputs to accomplish it.
Subversion has had a long history of distaste for environment
variables that alter its behavior. One user runs a command, and gets
something entirely different from another user with a different set of
environment variables. The config file is *exactly* the same sort of
monster. As a project, we avoided envvars so that posted recipes would
act the same for everybody using/reading them.
Now, maybe cache size is okay for the config since it doesn't affect
the operation, but... geez. Can we just stop inflating that file? So
much stuff gets hidden in there from the users' view.
"Wait.. HUH?! Why'd it do that?! ... oh, hell... stupid config
setting!! <forehead-slap>"
Cheers,
-g
Re: svn commit: r1079008 - /subversion/trunk/subversion/svnadmin/main.c
Posted by Philip Martin <ph...@wandisco.com>.
Stefan Sperling <st...@elego.de> writes:
> On Tue, Mar 08, 2011 at 02:15:06PM +0000, Philip Martin wrote:
>> Stefan Sperling <st...@elego.de> writes:
>>
>> > So I think it would be better if the cache was off by default, and must be
>> > enabled in a configuration file. I suppose svnserve and mod_dav_svn
>> > configuration files would be the best location for this,
>>
>> svnserve doesn't have a configuration file. There is a per-repository
>> configuration file, but as I understand it the cache is a per-process
>> entity affecting all the repositories.
>
> Ah, true. We could make it a command-line option, then.
It's already there: -M (--memory-cache-size).
>> > because the
>> > purpose of the cache seems to be to speed up server operation.
>> > An 'svn' process has a short lifetime so the benefit of this cache
>> > seems dubious in that situation. I don't see any reason to even provide
>> > a way to turn it on there.
>>
>> I guess it depends on the access patterns caused by the operations, it
>> might well speed up merge/diff/blame over ra_local/FSFS.
>
> Fair enough, but it should still be opt-in.
> We could add a config directive in ~/.subversion/config.
> If it turns out to be beneficial, users will enable it.
> However, since ra_local is used mostly for testing I don't expect this
> to be used much in practice. Our test suite might benefit.
svnadmin also reads .subversion/config and also has a -M option. Which
leads to my original questions: should we use the config file to
configure svn, should we have a -M option for svn, should we use the
config file for svnadmin, should we use the -M option for svnadmin.
--
Philip
Re: svn commit: r1079008 -
/subversion/trunk/subversion/svnadmin/main.c
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Mar 08, 2011 at 02:15:06PM +0000, Philip Martin wrote:
> Stefan Sperling <st...@elego.de> writes:
>
> > So I think it would be better if the cache was off by default, and must be
> > enabled in a configuration file. I suppose svnserve and mod_dav_svn
> > configuration files would be the best location for this,
>
> svnserve doesn't have a configuration file. There is a per-repository
> configuration file, but as I understand it the cache is a per-process
> entity affecting all the repositories.
Ah, true. We could make it a command-line option, then.
> > because the
> > purpose of the cache seems to be to speed up server operation.
> > An 'svn' process has a short lifetime so the benefit of this cache
> > seems dubious in that situation. I don't see any reason to even provide
> > a way to turn it on there.
>
> I guess it depends on the access patterns caused by the operations, it
> might well speed up merge/diff/blame over ra_local/FSFS.
Fair enough, but it should still be opt-in.
We could add a config directive in ~/.subversion/config.
If it turns out to be beneficial, users will enable it.
However, since ra_local is used mostly for testing I don't expect this
to be used much in practice. Our test suite might benefit.
Re: svn commit: r1079008 - /subversion/trunk/subversion/svnadmin/main.c
Posted by Philip Martin <ph...@wandisco.com>.
Stefan Sperling <st...@elego.de> writes:
> So I think it would be better if the cache was off by default, and must be
> enabled in a configuration file. I suppose svnserve and mod_dav_svn
> configuration files would be the best location for this,
svnserve doesn't have a configuration file. There is a per-repository
configuration file, but as I understand it the cache is a per-process
entity affecting all the repositories.
> because the
> purpose of the cache seems to be to speed up server operation.
> An 'svn' process has a short lifetime so the benefit of this cache
> seems dubious in that situation. I don't see any reason to even provide
> a way to turn it on there.
I guess it depends on the access patterns caused by the operations, it
might well speed up merge/diff/blame over ra_local/FSFS.
--
Philip
Re: svn commit: r1079008 -
/subversion/trunk/subversion/svnadmin/main.c
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Mar 08, 2011 at 01:46:23PM +0000, Philip Martin wrote:
> stefan2@apache.org writes:
>
> > Author: stefan2
> > Date: Mon Mar 7 22:57:04 2011
> > New Revision: 1079008
> >
> > URL: http://svn.apache.org/viewvc?rev=1079008&view=rev
> > Log:
> > Set FSFS cache default size to 16 MB. This is the same default as
> > for everybody else, namely the server processes. Thus, it should
> > be reasonable value on the same machines.
>
> 16MB may be "reasonable" for normal usage but it still has a significant
> effect on the testsuite. The testsuite is an unusual access pattern, it
> runs thousands of commands on small repositories. Using a 1MB cache I
> can run the testsuite for ra_local/FSFS in 10m15s, with 16MB cache that
> increases to 12m30s, a 20% increase. There is a similar increase when
> testing ra_svn/FSFS using the default Linux svnserve (a threaded
> svnserve has a shared cache so isn't affected).
>
> svnserve and svnadmin both have a -M option, was there any discussion
> about using a single letter option for this feature? This could be used
> by the testuite to restrict the cache size, but for ra_local/FSFS
> testing there is no way to restrict the svn client.
Shouldn't the cache be off by default?
We have precedence for other features like this that are strictly opt-in,
e.g. memcached support in FSFS. I don't think we should assume that the
new cache code is perfect and enable it by default on any repository for
any 1.7 server. The feature has not had any exposure in the real world yet.
So I think it would be better if the cache was off by default, and must be
enabled in a configuration file. I suppose svnserve and mod_dav_svn
configuration files would be the best location for this, because the
purpose of the cache seems to be to speed up server operation.
An 'svn' process has a short lifetime so the benefit of this cache
seems dubious in that situation. I don't see any reason to even provide
a way to turn it on there.
Re: svn commit: r1079008 - /subversion/trunk/subversion/svnadmin/main.c
Posted by Philip Martin <ph...@wandisco.com>.
Greg Stein <gs...@gmail.com> writes:
> We make changes. We break the code. We make it worse. We fix it, and
> move on.
Thanks, Greg. I certainly don't want Stefan to feel that I am putting
barriers in his way. I probably should have put more effort into
getting my questions right.
--
Philip
Re: svn commit: r1079008 - /subversion/trunk/subversion/svnadmin/main.c
Posted by Greg Stein <gs...@gmail.com>.
On ... wrote:
>...
> Was there any discussion about this overcommit behaviour?
This is the second or third time that I've seen "was there any
discussion" raised as a point. This raises a small yellow flag for me.
We all make changes to the codebase, and many of them are *NOT*
discussed before hand. We simply do what we think is best for
Subversion. But raising the spectre of "did you talk to 'us' before
doing this" seems to intrude on the rights/responsibilities that we
have as committers. It seems to be erecting a gate.
Subversion has always been commit-then-review (CTR). Changes are made
by the developers, and then subject to review by the other devs and
interested watchers. The only real time that we have requested review
*before* commits is for large new features (e.g. patch, obliterate,
etc). But even then, a lot of work is typically done to "hide" the
work until it matures. We've sometimes used branches to await maturity
(but IMO, that usually fails because people tend to NOT review branch
work).
Of course, it is completely legit to ask "is there prior
research/discussion/input that went into this feature that you can
point me to [so I can educate myself]", but I'm a bit wary of
situations where it seems to be implying that a change should not have
been made because there was no discussion.
We make changes. We break the code. We make it worse. We fix it, and move on.
Cheers,
-g
Re: svn commit: r1079008 - /subversion/trunk/subversion/svnadmin/main.c
Posted by Stefan Fuhrmann <eq...@web.de>.
On 09.03.2011 11:56, Philip Martin wrote:
> Stefan Fuhrmann<eq...@web.de> writes:
>
>> On 08.03.2011 14:46, Philip Martin wrote:
>>> stefan2@apache.org writes:
>>>
>>>> Author: stefan2
>>>> Date: Mon Mar 7 22:57:04 2011
>>>> New Revision: 1079008
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=1079008&view=rev
>>>> Log:
>>>> Set FSFS cache default size to 16 MB. This is the same default as
>>>> for everybody else, namely the server processes. Thus, it should
>>>> be reasonable value on the same machines.
>>> 16MB may be "reasonable" for normal usage but it still has a significant
>>> effect on the testsuite. The testsuite is an unusual access pattern, it
>>> runs thousands of commands on small repositories. Using a 1MB cache I
>>> can run the testsuite for ra_local/FSFS in 10m15s, with 16MB cache that
>>> increases to 12m30s, a 20% increase. There is a similar increase when
>>> testing ra_svn/FSFS using the default Linux svnserve (a threaded
>>> svnserve has a shared cache so isn't affected).
>> The patch attached fixes the performance penalty
>> for "make check" by disabling membuffer caches
>> over ra_local by default. Since svn_ra_initialize is
>> being called early in main(), the setting can later
>> be overwritten by settings from e.g. a config file.
>>
>> Could you verify that / whether this fixes your
>> performance issue?
> It goes some way, but it's not as good as setting the cache size to 1MB
> since it doesn't affect the svnadmin dump/load commands used by most of
> the tests.
I think we should commit that change, then. But I'm not
perfectly sure that the ra_loader initialization code it is
a good place to put it. It seems to be one of the central
places where it could be done consistently.
>>> svnserve and svnadmin both have a -M option, was there any discussion
>>> about using a single letter option for this feature?
>> No.
>>> This could be used
>>> by the testuite to restrict the cache size, but for ra_local/FSFS
>>> testing there is no way to restrict the svn client.
>> As already shown in a different thread, the memory
>> consumption should actually go down for any non-
>> trivial repository.
>>> Should we add the -M option to the svn client?
>> Due to its limited applicability (FSFS via file:/// only),
> There may well be large numbers of people using that for private
> repositories.
With the cache statistics feature we talked about lately
on IRC, we should get reliable data whether ra_local
will benefit from it at all. Having thought about that for
some time now, it seems that even diff and annotate
might not benefit.
The TSVN repository browser, in fact, might be one
of the few applications that causes significant numbers
of cache hits.
> As I undertand it cache initialisation includes setting the memory to
> zero, and that this is partly to ensure that all the allocated memory is
> really available to the process on a Linux system with overcommit
> enabled.
Exactly. I wanted to prevent a behavior that looks like
a memory leak. Non-threaded servers should now
be more likely to detect the OOM condition and fall
back to the hopefully smaller 1.6 caching scheme.
> If the cache had a more lightweight initialisation then a
> cache size of 16MB would probably not be a problem.
The index part needs to be initialized but covers only
1/16th of the whole cache memory. So, yes, no zeroing
the data memory will bring performance back.
> Was there any
> discussion about this overcommit behaviour? Linux overcommit is
> configurable, why should Subversion override this?
It would a service to all these LAMP V-server users
that might not be aware about the overcommit feature
at all.
> It doesn't apply to
> all the other memory allocation in Subversion, so what guarantee are you
> trying to provide and what are you actually providing?
Good point. You got me convinced: the 1.6 caches
will grow slowly while getting filled and without zeroing,
the membuffer cache will apparently do the same.
Committed in r1081082.
-- Stefan^2.
Re: svn commit: r1079008 - /subversion/trunk/subversion/svnadmin/main.c
Posted by Philip Martin <ph...@wandisco.com>.
Stefan Fuhrmann <eq...@web.de> writes:
> On 08.03.2011 14:46, Philip Martin wrote:
>> stefan2@apache.org writes:
>>
>>> Author: stefan2
>>> Date: Mon Mar 7 22:57:04 2011
>>> New Revision: 1079008
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1079008&view=rev
>>> Log:
>>> Set FSFS cache default size to 16 MB. This is the same default as
>>> for everybody else, namely the server processes. Thus, it should
>>> be reasonable value on the same machines.
>> 16MB may be "reasonable" for normal usage but it still has a significant
>> effect on the testsuite. The testsuite is an unusual access pattern, it
>> runs thousands of commands on small repositories. Using a 1MB cache I
>> can run the testsuite for ra_local/FSFS in 10m15s, with 16MB cache that
>> increases to 12m30s, a 20% increase. There is a similar increase when
>> testing ra_svn/FSFS using the default Linux svnserve (a threaded
>> svnserve has a shared cache so isn't affected).
> The patch attached fixes the performance penalty
> for "make check" by disabling membuffer caches
> over ra_local by default. Since svn_ra_initialize is
> being called early in main(), the setting can later
> be overwritten by settings from e.g. a config file.
>
> Could you verify that / whether this fixes your
> performance issue?
It goes some way, but it's not as good as setting the cache size to 1MB
since it doesn't affect the svnadmin dump/load commands used by most of
the tests.
>> svnserve and svnadmin both have a -M option, was there any discussion
>> about using a single letter option for this feature?
> No.
>> This could be used
>> by the testuite to restrict the cache size, but for ra_local/FSFS
>> testing there is no way to restrict the svn client.
> As already shown in a different thread, the memory
> consumption should actually go down for any non-
> trivial repository.
>> Should we add the -M option to the svn client?
> Due to its limited applicability (FSFS via file:/// only),
There may well be large numbers of people using that for private
repositories.
As I undertand it cache initialisation includes setting the memory to
zero, and that this is partly to ensure that all the allocated memory is
really available to the process on a Linux system with overcommit
enabled. If the cache had a more lightweight initialisation then a
cache size of 16MB would probably not be a problem. Was there any
discussion about this overcommit behaviour? Linux overcommit is
configurable, why should Subversion override this? It doesn't apply to
all the other memory allocation in Subversion, so what guarantee are you
trying to provide and what are you actually providing?
--
Philip
Re: svn commit: r1079008 - /subversion/trunk/subversion/svnadmin/main.c
Posted by Stefan Fuhrmann <eq...@web.de>.
On 08.03.2011 14:46, Philip Martin wrote:
> stefan2@apache.org writes:
>
>> Author: stefan2
>> Date: Mon Mar 7 22:57:04 2011
>> New Revision: 1079008
>>
>> URL: http://svn.apache.org/viewvc?rev=1079008&view=rev
>> Log:
>> Set FSFS cache default size to 16 MB. This is the same default as
>> for everybody else, namely the server processes. Thus, it should
>> be reasonable value on the same machines.
> 16MB may be "reasonable" for normal usage but it still has a significant
> effect on the testsuite. The testsuite is an unusual access pattern, it
> runs thousands of commands on small repositories. Using a 1MB cache I
> can run the testsuite for ra_local/FSFS in 10m15s, with 16MB cache that
> increases to 12m30s, a 20% increase. There is a similar increase when
> testing ra_svn/FSFS using the default Linux svnserve (a threaded
> svnserve has a shared cache so isn't affected).
The patch attached fixes the performance penalty
for "make check" by disabling membuffer caches
over ra_local by default. Since svn_ra_initialize is
being called early in main(), the setting can later
be overwritten by settings from e.g. a config file.
Could you verify that / whether this fixes your
performance issue?
> svnserve and svnadmin both have a -M option, was there any discussion
> about using a single letter option for this feature?
No.
> This could be used
> by the testuite to restrict the cache size, but for ra_local/FSFS
> testing there is no way to restrict the svn client.
As already shown in a different thread, the memory
consumption should actually go down for any non-
trivial repository.
> Should we add the -M option to the svn client?
Due to its limited applicability (FSFS via file:/// only),
I'm kind of -0 on adding that to the client. It is clearly
useful in certain cases but it may be hard to make
that clear to the average user.
It seems more likely to be a "on server" feature: run
svn (or others) from hook scripts. For max. speed,
admins could tweak their svn config file accordingly.
> Should we make it configurable via .subversion/config instead or as well?
See above.
> If svnadmin gets configured by .subversion/config should we remove the
> command line option?
I'm +0 for the config file. For me, the CL is slightly
more convenient as it is easier to play with different
parameter values. The config file has the advantage
that each setting can be extensively documented /
commented.
-- Stefan^2.