You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Max Bowsher <ma...@ukf.net> on 2005/01/13 10:56:11 UTC
tsvn:logwidth in svn repository (Re: svn commit: r12696 - trunk/subversion/po)
luebbe@tigris.org wrote:
> Author: luebbe
> Date: Thu Jan 13 03:11:19 2005
> New Revision: 12696
>
> Modified:
> trunk/subversion/po/ (props changed)
> trunk/subversion/po/de.po
> Log:
> Update to German translation:
>
> * subversion/po/: Set the tsvn:logwidth marker on the directory to 80
> characters so that I and others don't accidentaly enter too long log
> messages. Look, it's already working :-)
*If* this is going to be set anywhere, shouldn't it be on the root of the
repository? Or possibly, on trunk?
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>.
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
Re: tsvn:logwidth in svn repository
Posted by steveking <st...@gmx.ch>.
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by Will Dean <sv...@indcomp.co.uk>.
"Branko Cibej" <br...@xbc.nu> wrote in message news:41EE8230.50102@xbc.nu...
> Of course, the stranger part of the story is that you said that TSVN would
> always use its own copy of the DLLs, even if the "regular" binaries
> provided them, so I'm a bit perplexed as to why you'd need a DLL in the
> first place.
Well, TSVN is more than one application/DLL, so with static linking there
are multiple copies of the library in the distribution.
Will
---------------------------------------------------------------------
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by Branko Čibej <br...@xbc.nu>.
SteveKing wrote:
> 2. A bigger patch to make Subversion build as a dll on windows to
> avoid static linking:
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=33674
> Got rejected because (even though the patch uses the exact same
> approach as apr does) it wasn't the way the devs wanted it done. A
> generator for def files was the choice, but Subversion doesn't build
> as a dll even almost two years later...
In this particular case, I think I and others explained well enough why
APR's approach isn't appropriate for Subversion (or rather, why its
broken), and how we do want it done. I can only guess that you decided
that you don't want to work towards the accepted design. Fair enough,
that's your call. And others, myself included, obviously don't think
having SVN DLLs on Windows is all that important. (As far as I'm
concerned, it's a "nice to have", but I don't have time for it.)
Of course, the stranger part of the story is that you said that TSVN
would always use its own copy of the DLLs, even if the "regular"
binaries provided them, so I'm a bit perplexed as to why you'd need a
DLL in the first place.
-- Brane
---------------------------------------------------------------------
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by kf...@collab.net.
Barry Scott <ba...@barrys-emacs.org> writes:
> I'm guessing that outside of the core subversion members few people
> have any idea what your
> development goals and plans are.
>
> For example the client API rewrite is talked about when problems are
> discussed but I have no
> idea when such work might begin. I see little point in talking further
> about problems that will not
> see fixes for years.
Was this in response to something specific? (You didn't quote any
text, and I'm not sure exactly who it's addressed to.)
I'm not familiar with any conversations about a client API rewrite.
In general, any concrete plans are put on the public status/roadmap
pages, or are arranged by target release in the issue tracker. When
something *isn't* represented in one of these publicly visible ways,
it just means there isn't a concrete plan to do it yet. But the way
things go from "no concrete plan" to "scheduled for release" is by
talking about them, so I can't quite agree with the (implied?)
pessimism of your last sentence...
Best,
-Karl
---------------------------------------------------------------------
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by Barry Scott <ba...@barrys-emacs.org>.
I'm guessing that outside of the core subversion members few people
have any idea what your
development goals and plans are.
For example the client API rewrite is talked about when problems are
discussed but I have no
idea when such work might begin. I see little point in talking further
about problems that will not
see fixes for years.
Barry
---------------------------------------------------------------------
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by kf...@collab.net.
SteveKing <st...@gmx.ch> writes:
> I know that patches get rejected for several reasons. And I know it's
> not just my patches. I just wanted to point out that (for me anyway,
> since I don't know all the subversion code inside out) a patch which
> would have implemented repository configs would have been rejected for
> sure. That's why I didn't do it myself, and that's why I don't
> understand such comments like "why didn't you write a patch for
> subversion instead of the workaround in TSVN".
Well, the issue with repository configs isn't so much the patch
itself, as the design discussion that would have to precede the patch.
That discussion needs someone to drive it -- but it's certainly
understandable if you don't have time to be that person.
---------------------------------------------------------------------
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by SteveKing <st...@gmx.ch>.
kfogel@collab.net wrote:
[snip]
> It could be that you tend to tackle hard, complex problems where
> different people have very different approaches to the solutions.
> (The DLL thing might be an example of that, though I'm not
> knowledgeable enough about the problem to say for sure.) When you
> have posted reports and/or simple patches for obvious bugs, we have
> dealt with them promptly: r6664, r6175, r5936, r5190, and r4823 for
> example.
>
> So please don't just give up. Instead, try to guess whether a patch
> is likely to be simple and non-controversial, or likely to lead to
> long discussions. If you know the latter in advance, that might at
> least prepare you mentally for what's ahead.
I know that patches get rejected for several reasons. And I know it's
not just my patches. I just wanted to point out that (for me anyway,
since I don't know all the subversion code inside out) a patch which
would have implemented repository configs would have been rejected for
sure. That's why I didn't do it myself, and that's why I don't
understand such comments like "why didn't you write a patch for
subversion instead of the workaround in TSVN".
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by kf...@collab.net.
SteveKing <st...@gmx.ch> writes:
> 1. A three line patch making authentication work on Win98/Me systems
> because there the get_UID() function doesn't work:
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=37397
> Got rejected because it would belong into apr. But now, the
> authentication does exactly this - a little different of course
> because the whole auth stuff has been rewritten since then.
>
> 2. A bigger patch to make Subversion build as a dll on windows to
> avoid static linking:
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=33674
> Got rejected because (even though the patch uses the exact same
> approach as apr does) it wasn't the way the devs wanted it done. A
> generator for def files was the choice, but Subversion doesn't build
> as a dll even almost two years later...
>
> So you might see now why I don't write patches for Subversion
> anymore. I would just spend a lot of time which most likely would be
> for nothing -
> I'd rather spend that time on TSVN where I know it will do some good.
Stefan, I'm sorry you've had these experiences, but if you look
outside the horizons of what's happened to you personally, you have to
admit that we apply a LOT of patches from non-committer contributors.
If your patches get rejected more frequently than other people's, I
don't know what the reason is. It's certainly not prejudice -- if
anything, we're biased toward making you happy, because TSVN is so
important.
It could be that you tend to tackle hard, complex problems where
different people have very different approaches to the solutions.
(The DLL thing might be an example of that, though I'm not
knowledgeable enough about the problem to say for sure.) When you
have posted reports and/or simple patches for obvious bugs, we have
dealt with them promptly: r6664, r6175, r5936, r5190, and r4823 for
example.
So please don't just give up. Instead, try to guess whether a patch
is likely to be simple and non-controversial, or likely to lead to
long discussions. If you know the latter in advance, that might at
least prepare you mentally for what's ahead.
For what it's worth, I've made plenty of proposals for fixes recently
that have gone nowhere. Either people disagreed with the overall
approach, or they pointed out problems with the proposal that I didn't
see at first, or whatever. So it's not just you -- it's the nature of
the problem. Subversion has M developers and N things that need
doing, where M < N by a large factor. We have to prioritize.
-Karl
---------------------------------------------------------------------
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by Mark Benedetto King <mb...@lowlatency.com>.
On Fri, Jan 14, 2005 at 12:41:10PM -0600, kfogel@collab.net wrote:
> steveking <st...@gmx.ch> writes:
> > Three lines (that's the size of my patch) equals three months for
> > committing - now imagine me writing a patch which implements a new
> > feature ;)
>
> I have a lovely story for you, about how the size or apparent
> simplicity of a patch can be deceptive :-).
>
> >From http://en.wikipedia.org/wiki/Charles_Steinmetz:
http://www.snopes.com/business/genius/where.asp
--ben
---------------------------------------------------------------------
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by kf...@collab.net.
steveking <st...@gmx.ch> writes:
> Three lines (that's the size of my patch) equals three months for
> committing - now imagine me writing a patch which implements a new
> feature ;)
I have a lovely story for you, about how the size or apparent
simplicity of a patch can be deceptive :-).
Re: tsvn:logwidth in svn repository (Re: svn commit: r12696 -
trunk/subversion/po)
Posted by steveking <st...@gmx.ch>.
Greg Hudson wrote:
> On Fri, 2005-01-14 at 11:34, SteveKing wrote:
>
>>1. A three line patch making authentication work on Win98/Me systems
>>because there the get_UID() function doesn't work:
>>http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=37397
>>Got rejected because it would belong into apr. But now, the
>>authentication does exactly this - a little different of course because
>>the whole auth stuff has been rewritten since then.
>
>
> As far as I can tell, this was committed in r6695. (Which, to be fair,
> is three months later. But despite Branko's objections, your patch was
> eventually accepted.)
Three lines (that's the size of my patch) equals three months for
committing - now imagine me writing a patch which implements a new
feature ;)
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 (Re: svn commit: r12696 -
trunk/subversion/po)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2005-01-14 at 11:34, SteveKing wrote:
> 1. A three line patch making authentication work on Win98/Me systems
> because there the get_UID() function doesn't work:
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=37397
> Got rejected because it would belong into apr. But now, the
> authentication does exactly this - a little different of course because
> the whole auth stuff has been rewritten since then.
As far as I can tell, this was committed in r6695. (Which, to be fair,
is three months later. But despite Branko's objections, your patch was
eventually accepted.)
---------------------------------------------------------------------
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by SteveKing <st...@gmx.ch>.
Branko Čibej wrote:
> 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. :-/
>>
>> That's all I can do. It seems I'm just not able to explain why a
>> feature is needed so the svn devs usually agree to not do it.
>
> That.s BS. We know very well why this feature would be useful, it simply
> hasn't floated to the top of anyones priority list yet.
I didn't get that impression from previous discussions. And the comments
in the issue aren't so that I got the impression that Subversion will
ever have _custom_ repo configs.
>> After a while (usually as soon as someone else explains it better than
>> me) such features sometimes get implemented in Subversion after all.
>> But I can't always wait that long. So don't feel bad - it's my fault.
>
> There's one thing I don't understand: Why didn't you implement inherited
> props in the SVN code instead of mucking with workarounds in TSVN? It's
> not as if we reject good patches.
I've already sent several patches to this list. Every one of them got
rejected for different reasons. Put aside those that got rejected
because they wouldn't fit into Subversions concept, here two examples:
1. A three line patch making authentication work on Win98/Me systems
because there the get_UID() function doesn't work:
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=37397
Got rejected because it would belong into apr. But now, the
authentication does exactly this - a little different of course because
the whole auth stuff has been rewritten since then.
2. A bigger patch to make Subversion build as a dll on windows to avoid
static linking:
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=33674
Got rejected because (even though the patch uses the exact same approach
as apr does) it wasn't the way the devs wanted it done. A generator for
def files was the choice, but Subversion doesn't build as a dll even
almost two years later...
So you might see now why I don't write patches for Subversion anymore. I
would just spend a lot of time which most likely would be for nothing -
I'd rather spend that time on TSVN where I know it will do some good.
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by Branko Čibej <br...@xbc.nu>.
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. :-/
>
>
> That's all I can do. It seems I'm just not able to explain why a
> feature is needed so the svn devs usually agree to not do it.
That.s BS. We know very well why this feature would be useful, it simply
hasn't floated to the top of anyones priority list yet.
> After a while (usually as soon as someone else explains it better than
> me) such features sometimes get implemented in Subversion after all.
> But I can't always wait that long. So don't feel bad - it's my fault.
There's one thing I don't understand: Why didn't you implement inherited
props in the SVN code instead of mucking with workarounds in TSVN? It's
not as if we reject good patches.
-- Brane
---------------------------------------------------------------------
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by steveking <st...@gmx.ch>.
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. :-/
That's all I can do. It seems I'm just not able to explain why a feature
is needed so the svn devs usually agree to not do it.
After a while (usually as soon as someone else explains it better than
me) such features sometimes get implemented in Subversion after all. But
I can't always wait that long. So don't feel bad - 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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by Julian Foad <ju...@btopenworld.com>.
Folks, this discussion of inherited properties deserves a new thread name.
- Julian
---------------------------------------------------------------------
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by Branko Čibej <br...@xbc.nu>.
John Peacock wrote:
> Branko Čibej wrote:
>
>> You don't need a new table for _versioned_ inherited props, but you
>> do need one for unversioned inherited props -- i.e., ACLs.
>
>
> I thought you said that ACLs and inherited props were different
> things. ;)
Well, yes, in the sense that you don't can't keep ACLs cached in the WC.
-- Brane
---------------------------------------------------------------------
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by John Peacock <jp...@rowman.com>.
Branko Čibej wrote:
> What do you do with switched files whose "true" parents have a different
> prop value?
I'm not sure I know for sure what you are referring to here. Are you talking
about a mixed rev WC where the inherited property changed between revs on some
files? If you are using inherited properties, there is going to have to be more
use of 'svn up' to stay consistent.
Or are you talking about 'svn switch' to move a file from another branch (or
e.g. external) into a working copy. The external case is easier because the
inherited properties are associated with containing directory, so that falls
directly out since we don't support external links to files (yet). In the
switch case, I hadn't thought of that since I've only used switch in the context
of at least a directory (if not a tree).
What I've been thinking about is that the inherited property on the WC is a
property of the parent directory that a file is located in; hence mixed revs or
switched files only see the inherited property for the directory they are
located in right now. In the repository, however, the inherited properties are
merely a composite of all properties in the decomposition of the repository
local path (no complicated dual inheritance). In that respect, the only edge
case is what to do about branches (where you may want the inheritance to float)
vs tags (where you would definitely want the properties to be frozen). Those
cases are going to have to be dealt with by a commandline option and which is
the default is up in the air (I'm leaning towards copying the inherited
properties to any copied subtree as the default).
> Don't forget compatibility with generic DAV clients.
Hrm. If the server cannot determine that it is deal with a generic DAV client,
then that limits us to always populating the files as if they had the property
and worrying about inheritance only on the server. I suspect this would
actually be easier to code overall, but it would certainly be less efficient.
> You don't need a new table for _versioned_ inherited props, but you do
> need one for unversioned inherited props -- i.e., ACLs.
I thought you said that ACLs and inherited props were different things. ;)
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by Branko Čibej <br...@xbc.nu>.
John Peacock wrote:
> Branko Čibej wrote:
>
>> John Peacock wrote:
>>
>>> Inherited properties would solve this specific problem quite
>>> nicely. Of course now that I have spent a little time spelunking in
>>> the WC code, I'm not sure how practical that is going to be without
>>> a rewrite.
>>
>>
>>
>> The fact that a propertz is inherited is something the _server_
>> should worry about, not the WC. As far as the WC is concerned, there
>> should be almost no difference between an inherited property and any
>> other property.
>
>
> True, except to the extent that the WC code should at least know about
> properties that a _file_ has inherited from it's containing
> _directory_. For efficient storage of information in the WC, it would
> behoove us to at least smarten up the WC code to go that far. We
> wouldn't want the inherited properties to get stored for every single
> file in the WC, just the [much smaller] set of directories which have
> been checked out.
What do you do with switched files whose "true" parents have a different
prop value?
> For compatibility with downrev clients, however, the server could
> actually be smart enough to push the properties down to the file level
> (as actual properties now), but I don't think we would want this to be
> the default behavior.
Don't forget compatibility with generic DAV clients.
> However, this just gave me an idea: store the property in the
> repository on a directory as an svn:iprop and when the server adds it
> to some other subdirectory it reports it as an svn:vprop (virtual
> property). Then the client code can treat both of those as equivalent
> for purposes of container inheritance, yet only the former is editable.
It should still be possible to override the value deeper in the tree,
and -- as before -- don't ignore generic DAV clients.
> I'm trying not to require a new table in the repository (harder), so
> long as the table scan for inherited properties is quick and to the
> point...
You don't need a new table for _versioned_ inherited props, but you do
need one for unversioned inherited props -- i.e., ACLs.
(And please nobody tell me again that I can't talk about ACLs without
posting the ACL design...)
-- Brane
---------------------------------------------------------------------
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by John Peacock <jp...@rowman.com>.
Branko Čibej wrote:
> John Peacock wrote:
>
>> Inherited properties would solve this specific problem quite nicely.
>> Of course now that I have spent a little time spelunking in the WC
>> code, I'm not sure how practical that is going to be without a rewrite.
>
>
> The fact that a propertz is inherited is something the _server_ should
> worry about, not the WC. As far as the WC is concerned, there should be
> almost no difference between an inherited property and any other property.
True, except to the extent that the WC code should at least know about
properties that a _file_ has inherited from it's containing _directory_. For
efficient storage of information in the WC, it would behoove us to at least
smarten up the WC code to go that far. We wouldn't want the inherited
properties to get stored for every single file in the WC, just the [much
smaller] set of directories which have been checked out. For compatibility with
downrev clients, however, the server could actually be smart enough to push the
properties down to the file level (as actual properties now), but I don't think
we would want this to be the default behavior.
However, this just gave me an idea: store the property in the repository on a
directory as an svn:iprop and when the server adds it to some other subdirectory
it reports it as an svn:vprop (virtual property). Then the client code can
treat both of those as equivalent for purposes of container inheritance, yet
only the former is editable.
I'm trying not to require a new table in the repository (harder), so long as the
table scan for inherited properties is quick and to the point...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by Branko Čibej <br...@xbc.nu>.
John Peacock 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. :-/
>
>
> Inherited properties would solve this specific problem quite nicely.
> Of course now that I have spent a little time spelunking in the WC
> code, I'm not sure how practical that is going to be without a rewrite.
The fact that a propertz is inherited is something the _server_ should
worry about, not the WC. As far as the WC is concerned, there should be
almost no difference between an inherited property and any other property.
> The portion of the WC code dealing with the admin files is, by
> design, very focused on only the current directory. Hence referencing
> a parent's data is not easy (I'm not even sure I know enough to know
> whether it is even possible). And if you have only checked out a
> subtree, a round-trip to the server is necessary, of course.
>
> What would be much more workable would be for the RA layer to present
> virtual properties to the WC attached to the applicable directory.
Exactly.
> Then the WC code only needs to examine the current container for any
> inherited properties. When the client checks out a given directory,
> the server would calculate the inherited properties applicable to that
> directory and include that with any other properties set on the
> directory. This would mean that the proposed inherited properties
> would need an additional attribute, so you could tell from the client
> code whether this iprop was inherited from higher in the directory
> tree, or was the actual iprop itself.
-- Brane
---------------------------------------------------------------------
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by John Peacock <jp...@rowman.com>.
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. :-/
Inherited properties would solve this specific problem quite nicely. Of
course now that I have spent a little time spelunking in the WC code,
I'm not sure how practical that is going to be without a rewrite. The
portion of the WC code dealing with the admin files is, by design, very
focused on only the current directory. Hence referencing a parent's
data is not easy (I'm not even sure I know enough to know whether it is
even possible). And if you have only checked out a subtree, a
round-trip to the server is necessary, of course.
What would be much more workable would be for the RA layer to present
virtual properties to the WC attached to the applicable directory. Then
the WC code only needs to examine the current container for any
inherited properties. When the client checks out a given directory, the
server would calculate the inherited properties applicable to that
directory and include that with any other properties set on the
directory. This would mean that the proposed inherited properties would
need an additional attribute, so you could tell from the client code
whether this iprop was inherited from higher in the directory tree, or
was the actual iprop itself.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
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 (Re: svn commit: r12696 -
trunk/subversion/po)
Posted by Toby Johnson <to...@etjohnson.us>.
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. :-/
Which is exactly what will happen anytime lots of users request
something that you "ignore long enough". The interfaces that people
actually use the most (TSVN, Subclipse, etc.) will find a way around it
that isn't as clean as if it were officially implemented. The situation
you end up with is exactly the one you were trying to avoid.
---------------------------------------------------------------------
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jan 13, 2005, at 8:30 AM, Mark Phippard wrote:
> Julian Foad <ju...@btopenworld.com> wrote on 01/13/2005 09:16:28
> AM:
>
>> Functionally, this setting sounds like something that should be
> per-repository
>> (normally), not per-directory. It doesn't seem appropriate to set it
>> on
> just
>> one directory even if that will help a few people.
>
> Yes, that would be wonderful, but Subversion does not have the concept
> of
> per-repository settings so we had to improvise and use properties. We
> use
> the same techniques for the bug tracking integration. One advantage of
> properties is that it allows you to vary the settings by project.
> This is
> more useful for the bug tracking settings then the log width though.
>
> BTW, Subclipse supports these same properties.
>
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. :-/
---------------------------------------------------------------------
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by Mark Phippard <Ma...@softlanding.com>.
Julian Foad <ju...@btopenworld.com> wrote on 01/13/2005 09:16:28 AM:
> Functionally, this setting sounds like something that should be
per-repository
> (normally), not per-directory. It doesn't seem appropriate to set it on
just
> one directory even if that will help a few people.
Yes, that would be wonderful, but Subversion does not have the concept of
per-repository settings so we had to improvise and use properties. We use
the same techniques for the bug tracking integration. One advantage of
properties is that it allows you to vary the settings by project. This is
more useful for the bug tracking settings then the log width though.
BTW, Subclipse supports these same properties.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by Julian Foad <ju...@btopenworld.com>.
Lübbe Onken wrote:
> Max Bowsher wrote:
>> luebbe@tigris.org wrote:
>
>>> * subversion/po/: Set the tsvn:logwidth marker on the directory to 80
>
>> *If* this is going to be set anywhere, shouldn't it be on the root of
>> the repository? Or possibly, on trunk?
>
> setting this property recursively on trunk would be a good idea, but I
> didn't dare ;-). I don't know how many people are committing to the SVN
> repository via TSVN. Setting this property can only help, not harm.
> After all some svk properties are set on the repository as well.
Functionally, this setting sounds like something that should be per-repository
(normally), not per-directory. It doesn't seem appropriate to set it on just
one directory even if that will help a few people.
- Julian
---------------------------------------------------------------------
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by Lübbe Onken <l....@rac.de>.
Lübbe Onken wrote:
> setting this property recursively on trunk would be a good idea
I should have written: "recursively on all folders below and including
trunk."
If everyone checks out from trunk, setting the property on trunk alone
will be sufficient.
TortoiseSVN checks for its properties from the current location upwards,
so if people check out only parts of the subtree below trunk, TSVN won't
find it if it's only set on trunk.
Cheers
- Lübbe
--
___
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by steveking <st...@gmx.ch>.
Simon Large wrote:
> But it only needs to be set on folders, not on files, so don't use the
> recursive option unless you want to change _everything_ in the
> repository.
>
> You can set the property just on /trunk, but if anyone checks out only
> at a lower level, eg. for translations, then they won't see it.
You can set the properties recursively with TSVN: it automatically
checks if you want to set a tsvn: property and only applies it to
folders, not files.
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by Simon Large <sl...@blazepoint.co.uk>.
Lübbe Onken wrote:
> setting this property recursively on trunk would be a good idea, but I
> didn't dare ;-). I don't know how many people are committing to the
> SVN repository via TSVN. Setting this property can only help, not
> harm. After all some svk properties are set on the repository as well.
But it only needs to be set on folders, not on files, so don't use the
recursive option unless you want to change _everything_ in the
repository.
You can set the property just on /trunk, but if anyone checks out only
at a lower level, eg. for translations, then they won't see it.
Simon
---------------------------------------------------------------------
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by Max Bowsher <ma...@ukf.net>.
Peter N. Lundblad wrote:
> On Thu, 13 Jan 2005, Max Bowsher wrote:
>
>> Lübbe Onken wrote:
>>> After all some svk properties are set on the repository as well.
>>
>> But that was OK-ed on dev@ first.
>>
> Max,
>
> Is it that a big deal? If it makes life easier for someone, does it really
> hurt you? (As it turns out, it doesn't need to be set on each *file*.)
I'm not objecting to its presence.
I am objecting to its undiscussed presence, and the illogical-ness of
applying it to only one specific subtree of the repository.
Based on the info about tsvn behaviour that has been provided, I think the
correct thing to do would be to set it on each directory that would be the
root of a checkout for a substantial number of people.
i.e., trunk, trunk/subversion/po, and possibly some dirs for the book.
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 (Re: svn commit: r12696 -
trunk/subversion/po)
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Thu, 13 Jan 2005, Max Bowsher wrote:
> Lübbe Onken wrote:
> > After all some svk properties are set on the repository as well.
>
> But that was OK-ed on dev@ first.
>
Max,
Is it that a big deal? If it makes life easier for someone, does it really
hurt you? (As it turns out, it doesn't need to be set on each *file*.)
Regards,
//Peter
---------------------------------------------------------------------
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Jan 13, 2005 at 06:06:18PM -0000, Max Bowsher wrote:
>...
> "YUCK" to duplicating the information on every directory, and then having
> to remember to add it to newly created directories.
Fair enough, but inherited properties are even more of a bitch.
Depending upon the particular application, the inheritance approach
can really put a damper on performance.
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
Re: tsvn:logwidth in svn repository (Re: svn commit: r12696 - trunk/subversion/po)
Posted by Lübbe Onken <l....@rac.de>.
Max Bowsher wrote:
> "YUCK" to duplicating the information on every directory, and then
> having to remember to add it to newly created directories.
Didn't someone say "per-repository settings" in this thread? :-)
You're absolutely right "YUCK" describes the situation perfectly and
per-repository settings would be a perfect storage place for all these
properties we are talking about tsvn:logwidthmarker, bugtraq:message and
so on.
Cheers
- Lübbe
--
___
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by Max Bowsher <ma...@ukf.net>.
steveking wrote:
> Max Bowsher wrote:
>
>>> setting this property recursively on trunk would be a good idea,
>>
>> Recursively? YUCK!
>
> Why 'YUCK' ? Subversion provides the --recursive switch when setting
> properties, so that's not per se bad!
"YUCK" to duplicating the information on every directory, and then having to
remember to add it to newly created directories.
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by steveking <st...@gmx.ch>.
Max Bowsher wrote:
>> setting this property recursively on trunk would be a good idea,
>
> Recursively? YUCK!
Why 'YUCK' ? Subversion provides the --recursive switch when setting
properties, so that's not per se bad!
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by Max Bowsher <ma...@ukf.net>.
Lübbe Onken wrote:
> Max Bowsher wrote:
>> luebbe@tigris.org wrote:
> ...
>>> * subversion/po/: Set the tsvn:logwidth marker on the directory to 80
> ...
>> *If* this is going to be set anywhere, shouldn't it be on the root of
>> the repository? Or possibly, on trunk?
> setting this property recursively on trunk would be a good idea,
Recursively? YUCK!
In my (admittedly limited) reading of the TSVN webpages, I thought it
examined parent directories for tsvn: props?
> but I
> didn't dare ;-). I don't know how many people are committing to the SVN
> repository via TSVN. Setting this property can only help, not harm.
Except that there is no reason to just apply it to po.
Doing so is exactly the kind of piecemeal kludge that we try so hard to keep
out of the Subversion source code - I think we should be upholding the same
ethos of thoughtful design in our repository settings too.
> After all some svk properties are set on the repository as well.
But that was OK-ed on dev@ first.
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by Mark Phippard <Ma...@softlanding.com>.
Julian Foad <ju...@btopenworld.com> wrote on 01/13/2005 09:13:05 AM:
> Lübbe Onken wrote:
> > Max Bowsher wrote:
> >> luebbe@tigris.org wrote:
> >>> * subversion/po/: Set the tsvn:logwidth marker on the directory to
80
> >
> >> *If* this is going to be set anywhere, shouldn't it be on the root of
> >> the repository? Or possibly, on trunk?
> >
> > setting this property recursively on trunk would be a good idea, but I
> > didn't dare ;-). I don't know how many people are committing to the
SVN
> > repository via TSVN. Setting this property can only help, not harm.
> > After all some svk properties are set on the repository as well.
>
> On which directories or files does this property need to be set in order
for it
> to have the desired effect in TortoiseSVN? Does it need to be set on
every
> directory and/or file that might be the target of a commit? For
instance, if I
> do "svn ci doc/book/book/ch09.xml" then where does it need to be set?
TSVN will look up the hierarchy of folders in your WC to find the
property. So if you have a reasonable idea of what the top-level folders
are that users will checkout, then that is the only place you need to set
the property. Otherwise, it needs to be on every folder.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by Julian Foad <ju...@btopenworld.com>.
Lübbe Onken wrote:
> Max Bowsher wrote:
>> luebbe@tigris.org wrote:
>>> * subversion/po/: Set the tsvn:logwidth marker on the directory to 80
>
>> *If* this is going to be set anywhere, shouldn't it be on the root of
>> the repository? Or possibly, on trunk?
>
> setting this property recursively on trunk would be a good idea, but I
> didn't dare ;-). I don't know how many people are committing to the SVN
> repository via TSVN. Setting this property can only help, not harm.
> After all some svk properties are set on the repository as well.
On which directories or files does this property need to be set in order for it
to have the desired effect in TortoiseSVN? Does it need to be set on every
directory and/or file that might be the target of a commit? For instance, if I
do "svn ci doc/book/book/ch09.xml" then where does it need to be set?
- Julian
---------------------------------------------------------------------
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by Lübbe Onken <l....@rac.de>.
Max Bowsher wrote:
> luebbe@tigris.org wrote:
...
>> * subversion/po/: Set the tsvn:logwidth marker on the directory to 80
...
> *If* this is going to be set anywhere, shouldn't it be on the root of
> the repository? Or possibly, on trunk?
setting this property recursively on trunk would be a good idea, but I
didn't dare ;-). I don't know how many people are committing to the SVN
repository via TSVN. Setting this property can only help, not harm.
After all some svk properties are set on the repository as well.
--
Cheers
- Lübbe
--
___
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 (Re: svn commit: r12696 - trunk/subversion/po)
Posted by "Øyvind A. Holm" <su...@sunbase.org>.
On 2005-01-13 10:56:11 Max Bowsher wrote:
> luebbe@tigris.org wrote:
> > Author: luebbe
> > Date: Thu Jan 13 03:11:19 2005
> > New Revision: 12696
> >
> > Modified:
> > trunk/subversion/po/ (props changed)
> > [...]
> > * subversion/po/: Set the tsvn:logwidth marker on the directory to 80
> > characters so that I and others don't accidentaly enter too long log
> > messages. Look, it's already working :-)
>
> *If* this is going to be set anywhere, shouldn't it be on the root of the
> repository? Or possibly, on trunk?
The width of the dashes in "svn log" is already set to 72 characters, so
it would look nicer if using that value instead. And 80 characters is
too wide anyway, as it doesn't give room for quoting and possible
"flowed text"-spaces at the end of the lines.
Regards,
Øyvind A. Holm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org