You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by steveking <st...@gmx.ch> on 2005/01/13 16:53:36 UTC
Re: tsvn:logwidth in svn repository
Ben Collins-Sussman wrote:
> Well, users have been asking for server-settings that can be broadcast
> to clients for quite a while now.. I guess we've ignored the request
> long enough to the point that other projects have started improvising
> workaround solutions. :-/
As a sidenote: yes, this has come up on both dev@ and users@ list quite
often. When an issue got filed and I added some comments about having
custom config options, this was rejected right away - so I couldn't wait
for that to happen soon (if ever).
btw: the issue I'm talking about is 1974
http://subversion.tigris.org/issues/show_bug.cgi?id=1974
About how I think this could be done without breaking older clients at all:
define a file named 'svnrepoconfig' which resides in the repository
root. It's treated like a normal file, unless it's
1. located in the repository root
2. has a special new svn property set (e.g. svn:repoconfig = yes)
If those are true, then it's not a normal file anymore but one that
get's transferred on every update/commit. The client will store it
inside the config area, maybe in a subfolder called 'repoconfigs' right
beside 'auth' folder.
To reduce the data traffic, that file could even be 'versioned' like
other working copy files, with the difference that it's stored in the
config area.
That way,
- older clients won't break
- with mod_authz_svn you can set the access rights so that not everyone
can change those settings
- you don't need to contact the repository to get the configs - they're
stored locally so every client can access them immediatley if needed.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: tsvn:logwidth in svn repository
Posted by SteveKing <st...@gmx.ch>.
Ben Collins-Sussman wrote:
> Steve, maybe you can add these ideas to issue 1974?
[snip]
Ok, done.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: tsvn:logwidth in svn repository
Posted by Ben Collins-Sussman <su...@collab.net>.
Steve, maybe you can add these ideas to issue 1974?
On Jan 13, 2005, at 10:53 AM, steveking wrote:
> Ben Collins-Sussman wrote:
>
>> Well, users have been asking for server-settings that can be
>> broadcast to clients for quite a while now.. I guess we've ignored
>> the request long enough to the point that other projects have started
>> improvising workaround solutions. :-/
>
> As a sidenote: yes, this has come up on both dev@ and users@ list
> quite often. When an issue got filed and I added some comments about
> having custom config options, this was rejected right away - so I
> couldn't wait for that to happen soon (if ever).
> btw: the issue I'm talking about is 1974
> http://subversion.tigris.org/issues/show_bug.cgi?id=1974
>
> About how I think this could be done without breaking older clients at
> all:
> define a file named 'svnrepoconfig' which resides in the repository
> root. It's treated like a normal file, unless it's
> 1. located in the repository root
> 2. has a special new svn property set (e.g. svn:repoconfig = yes)
> If those are true, then it's not a normal file anymore but one that
> get's transferred on every update/commit. The client will store it
> inside the config area, maybe in a subfolder called 'repoconfigs'
> right beside 'auth' folder.
> To reduce the data traffic, that file could even be 'versioned' like
> other working copy files, with the difference that it's stored in the
> config area.
>
> That way,
> - older clients won't break
> - with mod_authz_svn you can set the access rights so that not
> everyone can change those settings
> - you don't need to contact the repository to get the configs -
> they're stored locally so every client can access them immediatley if
> needed.
>
> Stefan
>
> --
> ___
> oo // \\ "De Chelonian Mobile"
> (_,\/ \_/ \ TortoiseSVN
> \ \_/_\_/> The coolest Interface to (Sub)Version Control
> /_/ \_\ http://tortoisesvn.tigris.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: tsvn:logwidth in svn repository
Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2005-01-13 17:53+0100, steveking wrote:
I have an ideas how to do that a multi-repository way:
> About how I think this could be done without breaking older clients at all:
> define a file named 'svnrepoconfig' which resides in the repository
This should be a directory under repository which contains that config
file, because ...
> root. It's treated like a normal file, unless it's
> 1. located in the repository root
> 2. has a special new svn property set (e.g. svn:repoconfig = yes)
> If those are true, then it's not a normal file anymore but one that
> get's transferred on every update/commit. The client will store it
> inside the config area, maybe in a subfolder called 'repoconfigs' right
> beside 'auth' folder.
> To reduce the data traffic, that file could even be 'versioned' like
> other working copy files, with the difference that it's stored in the
> config area.
... this way the client could checkout that directory to the
.subversion/defaults/<REPO-UUID>, and we could have several configs
for several repositories. Also it is trivial to find which config
belongs to which repository.
BR, Jani
--
Jani Averbach
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: tsvn:logwidth in svn repository
Posted by "C. Michael Pilato" <cm...@collab.net>.
"C. Michael Pilato" <cm...@collab.net> writes:
> Ouch. I hope that in fact you are mistaking memories of particular
> negative experiences as just "experience with this list" -- that the
> dev-folk here aren't quite so bad in this way. Certainly if a single
> intelligent person raises a strong and valid concern about an idea, it
> behooves the rest of us to pay attention. But the dev-folk here are
> all human, and certainly not opposed to a little infighting from time
> to time. :-)
Oops. Sorry to follow up to myself to rapidly, but I made a rather
glaring error. It turns out that Max Bowsher actually *isn't* human,
but a well-tuned code-fixin' issue-slammin' rock-em-sock-em robot.
Apologies for the misinformation.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: tsvn:logwidth in svn repository
Posted by "C. Michael Pilato" <cm...@collab.net>.
SteveKing <st...@gmx.ch> writes:
> Max Bowsher wrote:
> > steveking wrote:
> >> As a sidenote: yes, this has come up on both dev@ and users@ list quite
> >> often. When an issue got filed and I added some comments about having
> >> custom config options, this was rejected right away - so I couldn't wait
> >> for that to happen soon (if ever).
> >> btw: the issue I'm talking about is 1974
> >> http://subversion.tigris.org/issues/show_bug.cgi?id=1974
> > I am puzzled as to what in issue 1974 could be construed as
> > 'rejection'.
>
> Check the comment from Greg Hudson.
> In my experience with this list, as soon as one Subversion dev doesn't
> like an idea I can give up trying to convince them - it won't be done.
Ouch. I hope that in fact you are mistaking memories of particular
negative experiences as just "experience with this list" -- that the
dev-folk here aren't quite so bad in this way. Certainly if a single
intelligent person raises a strong and valid concern about an idea, it
behooves the rest of us to pay attention. But the dev-folk here are
all human, and certainly not opposed to a little infighting from time
to time. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: tsvn:logwidth in svn repository
Posted by Max Bowsher <ma...@ukf.net>.
Greg Stein wrote:
> On Thu, Jan 13, 2005 at 06:23:10PM -0000, Max Bowsher wrote:
>> SteveKing wrote:
>>> Max Bowsher wrote:
>> ...
>>>> I am puzzled as to what in issue 1974 could be construed as
>>>> 'rejection'.
>> ...
>> *You* check the comment from Greg Hudson. He pointed out a necessary and
>> important security consideration to be kept in mind when designing a
>> solution. He did not exhibit any negative sentiment towards the core idea
>> whatsoever.
>>
>>> In my experience with this list, as soon as one Subversion dev doesn't
>>> like an idea I can give up trying to convince them - it won't be done.
>>
>> Well, that's a rather negative attitude.
>>
>> Please enumerate any cases in which you feel you have been mistreated,
>> and
>> I will attempt to eradicate any misunderstandings.
>
> I would venture that one example is the very tone that you're taking
> in the conversation. I'm not reading it as a "hey, let's explore this
> issue", but focusing more on Steve's reactions and commentary itself.
> Typically, meta-comments like that are taken personally rather than as
> a simple technical discussion.
Ok then - let me clarify my intended meaning:
"I'm annoyed at the uniform characterization of Subversion developers as
stubborn and unhelpful.
Rather than complain at this, I'd rather demonstrate that it is not true, by
either reopening past discussions and helping them to a satisfactory
conclusion, or at least explaining why a feature was not persued."
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: tsvn:logwidth in svn repository
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Jan 13, 2005 at 06:23:10PM -0000, Max Bowsher wrote:
> SteveKing wrote:
> >Max Bowsher wrote:
>...
> >>I am puzzled as to what in issue 1974 could be construed as 'rejection'.
>...
> *You* check the comment from Greg Hudson. He pointed out a necessary and
> important security consideration to be kept in mind when designing a
> solution. He did not exhibit any negative sentiment towards the core idea
> whatsoever.
>
> >In my experience with this list, as soon as one Subversion dev doesn't
> >like an idea I can give up trying to convince them - it won't be done.
>
> Well, that's a rather negative attitude.
>
> Please enumerate any cases in which you feel you have been mistreated, and
> I will attempt to eradicate any misunderstandings.
I would venture that one example is the very tone that you're taking
in the conversation. I'm not reading it as a "hey, let's explore this
issue", but focusing more on Steve's reactions and commentary itself.
Typically, meta-comments like that are taken personally rather than as
a simple technical discussion.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Repository-based client configuration schemes [was: tsvn:logwidth
in svn repository]
Posted by Julian Foad <ju...@btopenworld.com>.
Re-posting with a better Subject line.
- Julian
Rob Oxspring wrote:
Greg Hudson wrote:
> Actually, I do have a mild negative sentiment towards a "repository
> configuration" mehacnism, because almost any kind of "repository
> configuration" could, conceivably, want to vary within the repository.
> For instance, the Apache repository might very well have different
> projects which prefer different log widths.
>
> So, repository configuration seems like a good way to introduce
> configuration values with the wrong scope. I would rather see these
> things implemented as directory properties (as tsvn:logwidth already
> is), and make it easier to apply directory properties to whole
> subtrees.
This makes a lot of sense so adapting from Steve's and Jani's thoughts then,
how about adding a property that points to the configuration area for the
directory you are working on:
When setting up the project set the svn:configdir property of the project's
directory to point at the project's configuration directory:
svn propset svn:configdir ./config file:///path/to/repo/path/to/project/
When a checking out or updating a part of the project the server checks that
each directory has the server checks that svn:configdir has been set or
calculates a virtual property based on the parent directory's svn:configdir:
svn co file:///path/to/repo/path/to/project/component/
A blah.c
Checked out revision 22
Checking out configuration file:///path/to/repo/path/to/project/config
Checked out revision 22
The configuration gets checked out into:
~/.subversion/defaults/<UUID>/path/to/project/config
When committing files, the svn:configdir would be looked up from the
committables(*) and resolved to the relevent ~/.subversion subdir. This
directory would be used as the default configuration for the rest of the operation.
This scheme is pretty flexible and allows per-project repository-backed,
configuration defaults. The scheme lifts Steve's requirement that the config
directrory have specific name which I believe is closer to the subversion
ethos, but takes the essence of Jani's and Steve's ideas and adapts them to a
project level rather than repository level. If the value of svn:configdir was
allowed to be any url then the scheme would even support having multiple
'project' repositories sharing a single 'configuration' repository, a feature
which might well be useful to some.
Sorry for the drive by - one of these days I'll brush off my C skills and have
a play with the code properly but for now ideas are the best I can do.
Rob
* Obviously a big problem with any project level configuration mechanism is
that a commit could cover multiple projects with might point to different
config dirs. I suspect that the correct solution here would be to choose the
deepest common directory and grab the config from there but I haven't thought
through the implications of this yet.
> I'm not sure if property inheritance is the right mechanism
> (because it creates so many corner cases); perhaps the poor man's
> approach of auto-props is sufficient.
>
> Of course, auto-props is also a feature we implemented in the wrong
> scope. I would like to see auto-props redone as a directory property.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: tsvn:logwidth in svn repository
Posted by Rob Oxspring <ro...@imapmail.org>.
Greg Hudson wrote:
>
> Actually, I do have a mild negative sentiment towards a "repository
> configuration" mehacnism, because almost any kind of "repository
> configuration" could, conceivably, want to vary within the repository.
> For instance, the Apache repository might very well have different
> projects which prefer different log widths.
>
> So, repository configuration seems like a good way to introduce
> configuration values with the wrong scope. I would rather see these
> things implemented as directory properties (as tsvn:logwidth already
> is), and make it easier to apply directory properties to whole
> subtrees.
This makes a lot of sense so adapting from Steve's and Jani's thoughts then,
how about adding a property that points to the configuration area for the
directory you are working on:
When setting up the project set the svn:configdir property of the project's
directory to point at the project's configuration directory:
svn propset svn:configdir ./config file:///path/to/repo/path/to/project/
When a checking out or updating a part of the project the server checks that
each directory has the server checks that svn:configdir has been set or
calculates a virtual property based on the parent directory's svn:configdir:
svn co file:///path/to/repo/path/to/project/component/
A blah.c
Checked out revision 22
Checking out configuration file:///path/to/repo/path/to/project/config
Checked out revision 22
The configuration gets checked out into:
~/.subversion/defaults/<UUID>/path/to/project/config
When committing files, the svn:configdir would be looked up from the
committables(*) and resolved to the relevent ~/.subversion subdir. This
directory would be used as the default configuration for the rest of the
operation.
This scheme is pretty flexible and allows per-project repository-backed,
configuration defaults. The scheme lifts Steve's requirement that the config
directrory have specific name which I believe is closer to the subversion
ethos, but takes the essence of Jani's and Steve's ideas and adapts them to a
project level rather than repository level. If the value of svn:configdir was
allowed to be any url then the scheme would even support having multiple
'project' repositories sharing a single 'configuration' repository, a feature
which might well be useful to some.
Sorry for the drive by - one of these days I'll brush off my C skills and have
a play with the code properly but for now ideas are the best I can do.
Rob
* Obviously a big problem with any project level configuration mechanism is
that a commit could cover multiple projects with might point to different
config dirs. I suspect that the correct solution here would be to choose the
deepest common directory and grab the config from there but I haven't thought
through the implications of this yet.
> I'm not sure if property inheritance is the right mechanism
> (because it creates so many corner cases); perhaps the poor man's
> approach of auto-props is sufficient.
>
> Of course, auto-props is also a feature we implemented in the wrong
> scope. I would like to see auto-props redone as a directory property.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: tsvn:logwidth in svn repository
Posted by Max Bowsher <ma...@ukf.net>.
Greg Hudson wrote:
> On Thu, 2005-01-13 at 13:23, Max Bowsher wrote:
>> *You* check the comment from Greg Hudson. He pointed out a necessary and
>> important security consideration to be kept in mind when designing a
>> solution. He did not exhibit any negative sentiment towards the core idea
>> whatsoever.
>
> Actually, I do have a mild negative sentiment towards a "repository
> configuration" mehacnism, because almost any kind of "repository
> configuration" could, conceivably, want to vary within the repository.
OK - but you didn't express that in your existing comment in 1974.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: tsvn:logwidth in svn repository
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2005-01-13 at 13:23, Max Bowsher wrote:
> *You* check the comment from Greg Hudson. He pointed out a necessary and
> important security consideration to be kept in mind when designing a
> solution. He did not exhibit any negative sentiment towards the core idea
> whatsoever.
Actually, I do have a mild negative sentiment towards a "repository
configuration" mehacnism, because almost any kind of "repository
configuration" could, conceivably, want to vary within the repository.
For instance, the Apache repository might very well have different
projects which prefer different log widths.
So, repository configuration seems like a good way to introduce
configuration values with the wrong scope. I would rather see these
things implemented as directory properties (as tsvn:logwidth already
is), and make it easier to apply directory properties to whole
subtrees. I'm not sure if property inheritance is the right mechanism
(because it creates so many corner cases); perhaps the poor man's
approach of auto-props is sufficient.
Of course, auto-props is also a feature we implemented in the wrong
scope. I would like to see auto-props redone as a directory property.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: tsvn:logwidth in svn repository
Posted by Max Bowsher <ma...@ukf.net>.
SteveKing wrote:
> Max Bowsher wrote:
>
>>>> I am puzzled as to what in issue 1974 could be construed as
>>>> 'rejection'.
>>>
>>> Check the comment from Greg Hudson.
>>
>> *You* check the comment from Greg Hudson. He pointed out a necessary and
>> important security consideration to be kept in mind when designing a
>> solution. He did not exhibit any negative sentiment towards the core
>> idea whatsoever.
>
> And what do you think does "So, let me suppress that idea" mean?
> Suppressing means (at least in my dictionary) not allowing something by
> force.
Indeed, he's forcibly suppressing any contemplation of letting the server
execute arbitrary code on the client.
>>> In my experience with this list, as soon as one Subversion dev doesn't
>>> like an idea I can give up trying to convince them - it won't be done.
>>
>> Well, that's a rather negative attitude.
>>
>> Please enumerate any cases in which you feel you have been mistreated,
>> and I will attempt to eradicate any misunderstandings.
>
> Feel free to search the list. There are various discussions where I got
> nowhere.
> But as I said: it's my fault.
Eager as I am to help further the development of successful relationships
with svn-dependant projects, I'm not eager enough to trawl through years of
mail archives.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: tsvn:logwidth in svn repository
Posted by SteveKing <st...@gmx.ch>.
Max Bowsher wrote:
>>> I am puzzled as to what in issue 1974 could be construed as 'rejection'.
>>
>> Check the comment from Greg Hudson.
>
> *You* check the comment from Greg Hudson. He pointed out a necessary and
> important security consideration to be kept in mind when designing a
> solution. He did not exhibit any negative sentiment towards the core
> idea whatsoever.
And what do you think does "So, let me suppress that idea" mean?
Suppressing means (at least in my dictionary) not allowing something by
force.
>> In my experience with this list, as soon as one Subversion dev doesn't
>> like an idea I can give up trying to convince them - it won't be done.
>
> Well, that's a rather negative attitude.
>
> Please enumerate any cases in which you feel you have been mistreated,
> and I will attempt to eradicate any misunderstandings.
Feel free to search the list. There are various discussions where I got
nowhere.
But as I said: it's my fault.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: tsvn:logwidth in svn repository
Posted by Max Bowsher <ma...@ukf.net>.
SteveKing wrote:
> Max Bowsher wrote:
>> steveking wrote:
>>> As a sidenote: yes, this has come up on both dev@ and users@ list quite
>>> often. When an issue got filed and I added some comments about having
>>> custom config options, this was rejected right away - so I couldn't wait
>>> for that to happen soon (if ever).
>>> btw: the issue I'm talking about is 1974
>>> http://subversion.tigris.org/issues/show_bug.cgi?id=1974
>>
>>
>> I am puzzled as to what in issue 1974 could be construed as 'rejection'.
>
> Check the comment from Greg Hudson.
*You* check the comment from Greg Hudson. He pointed out a necessary and
important security consideration to be kept in mind when designing a
solution. He did not exhibit any negative sentiment towards the core idea
whatsoever.
> In my experience with this list, as soon as one Subversion dev doesn't
> like an idea I can give up trying to convince them - it won't be done.
Well, that's a rather negative attitude.
Please enumerate any cases in which you feel you have been mistreated, and I
will attempt to eradicate any misunderstandings.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: tsvn:logwidth in svn repository
Posted by SteveKing <st...@gmx.ch>.
Max Bowsher wrote:
> steveking wrote:
>> As a sidenote: yes, this has come up on both dev@ and users@ list quite
>> often. When an issue got filed and I added some comments about having
>> custom config options, this was rejected right away - so I couldn't wait
>> for that to happen soon (if ever).
>> btw: the issue I'm talking about is 1974
>> http://subversion.tigris.org/issues/show_bug.cgi?id=1974
>
>
> I am puzzled as to what in issue 1974 could be construed as 'rejection'.
Check the comment from Greg Hudson.
In my experience with this list, as soon as one Subversion dev doesn't
like an idea I can give up trying to convince them - it won't be done.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: tsvn:logwidth in svn repository
Posted by Max Bowsher <ma...@ukf.net>.
steveking wrote:
> Ben Collins-Sussman wrote:
>
>> Well, users have been asking for server-settings that can be broadcast
>> to clients for quite a while now.. I guess we've ignored the request
>> long enough to the point that other projects have started improvising
>> workaround solutions. :-/
>
> As a sidenote: yes, this has come up on both dev@ and users@ list quite
> often. When an issue got filed and I added some comments about having
> custom config options, this was rejected right away - so I couldn't wait
> for that to happen soon (if ever).
> btw: the issue I'm talking about is 1974
> http://subversion.tigris.org/issues/show_bug.cgi?id=1974
I am puzzled as to what in issue 1974 could be construed as 'rejection'.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org