You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Vlad Skvortsov <vs...@73rus.com> on 2006/10/02 19:44:57 UTC
Re: Custom keywords, issue #890
Garrett Rooney wrote:
> On 9/28/06, Vlad Skvortsov <vs...@73rus.com> wrote:
>
>> This leads to another requirement: autoprops should be customizable on
>> per-repository basis. But it seems to me that it's a much simplier
>> problem to solve than rolling out iprops or whatever.
>
>
> The problem (as with most server-side config type questions) is that
> you don't necessarily want it to be per-repository, because a
> repository may contain many different projects (look at the ASF
> subversion repository on svn.apache.org for example) that have wildly
> differing standards with regard to things like properties. So you
> need to be able to set them on a per-project basis, then you run into
> the fact that there's no really well defined "project" in svn, so you
> need to be able to set them on an arbitrary directory. Oops, now
> you're talking about inherited properties again.
>
> Now, it's not necesarily the crazy complex inherited properties some
> people talk about, there are ways to implement it that are simpler (a
> proposal was floated around on this list a while back that involved a
> special new command that just asks the server "does this property
> exist on this directory or any of its parents", which wouldn't be that
> bad to implement, but nobody has actually done it yet.
>
> So unfortunately, one way or another you do get back to inherited
> properties in some form ;-)
I still don't see a need for inherited properties here though. Given
that pre-commit hook ensures keywords are properly set up, this boils
down to a configuration problem. And why not use something as simple as:
[autoprops-set-freebsd]
FreeBSD = %r
[repository-freebsd]
# Any of these URLs match.
url = https://svn.freebsd.org/
url = svn://svn-freebsd.lan/
# ... in conjunction with any of these paths within repository.
path = /main
path = /another-subtree/project-a
# Use this autoprops setting for the match.
autoprops = autoprops-set-freebsd
The problem here is that pre-commit hook and clients' autoprops settings
need to be kept in sync. The proper way to solve this for a long term
seems to be to configure that on server side and let clients discover
the settings.
However, in the meanwhile it is possible to solve the problem at hand
without both iprops and "server-side autoprops".
--
Vlad Skvortsov, vss@73rus.com, http://vss.73rus.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Custom keywords, issue #890
Posted by Vlad Skvortsov <vs...@73rus.com>.
Garrett Rooney wrote:
>>
>> [autoprops-set-freebsd]
>> FreeBSD = %r
>>
>> [repository-freebsd]
>> # Any of these URLs match.
>> url = https://svn.freebsd.org/
>> url = svn://svn-freebsd.lan/
>> # ... in conjunction with any of these paths within repository.
>> path = /main
>> path = /another-subtree/project-a
>> # Use this autoprops setting for the match.
>> autoprops = autoprops-set-freebsd
>>
>> The problem here is that pre-commit hook and clients' autoprops settings
>> need to be kept in sync. The proper way to solve this for a long term
>> seems to be to configure that on server side and let clients discover
>> the settings.
>
>
> A solution to which is yet another case where iprops would be nice...
True.
>> However, in the meanwhile it is possible to solve the problem at hand
>> without both iprops and "server-side autoprops".
>
>
> Sure, possibly, but it's a kindof half-assed solution, just like the
> current autoprops stuff is. Now, that's not to say that I'd object to
> a well done half-assed solution, as long as it doesn't keep us from
> implementing a better one sometime down the road.
Half-assed solution *now* is better than proper solution *never*, isn't it?
I think having quick solution will benefit in:
1) setting Subversion ahead of competition for such projects as *BSDs,
which is a good publicity;
2) better understaning of the problem at hand, to craft better proper
solution.
--
Vlad Skvortsov, vss@73rus.com, http://vss.73rus.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Custom keywords, issue #890
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 10/2/06, Vlad Skvortsov <vs...@73rus.com> wrote:
> Garrett Rooney wrote:
>
> > On 9/28/06, Vlad Skvortsov <vs...@73rus.com> wrote:
> >
> >> This leads to another requirement: autoprops should be customizable on
> >> per-repository basis. But it seems to me that it's a much simplier
> >> problem to solve than rolling out iprops or whatever.
> >
> >
> > The problem (as with most server-side config type questions) is that
> > you don't necessarily want it to be per-repository, because a
> > repository may contain many different projects (look at the ASF
> > subversion repository on svn.apache.org for example) that have wildly
> > differing standards with regard to things like properties. So you
> > need to be able to set them on a per-project basis, then you run into
> > the fact that there's no really well defined "project" in svn, so you
> > need to be able to set them on an arbitrary directory. Oops, now
> > you're talking about inherited properties again.
> >
> > Now, it's not necesarily the crazy complex inherited properties some
> > people talk about, there are ways to implement it that are simpler (a
> > proposal was floated around on this list a while back that involved a
> > special new command that just asks the server "does this property
> > exist on this directory or any of its parents", which wouldn't be that
> > bad to implement, but nobody has actually done it yet.
> >
> > So unfortunately, one way or another you do get back to inherited
> > properties in some form ;-)
>
> I still don't see a need for inherited properties here though. Given
> that pre-commit hook ensures keywords are properly set up, this boils
> down to a configuration problem. And why not use something as simple as:
>
> [autoprops-set-freebsd]
> FreeBSD = %r
>
> [repository-freebsd]
> # Any of these URLs match.
> url = https://svn.freebsd.org/
> url = svn://svn-freebsd.lan/
> # ... in conjunction with any of these paths within repository.
> path = /main
> path = /another-subtree/project-a
> # Use this autoprops setting for the match.
> autoprops = autoprops-set-freebsd
>
> The problem here is that pre-commit hook and clients' autoprops settings
> need to be kept in sync. The proper way to solve this for a long term
> seems to be to configure that on server side and let clients discover
> the settings.
A solution to which is yet another case where iprops would be nice...
> However, in the meanwhile it is possible to solve the problem at hand
> without both iprops and "server-side autoprops".
Sure, possibly, but it's a kindof half-assed solution, just like the
current autoprops stuff is. Now, that's not to say that I'd object to
a well done half-assed solution, as long as it doesn't keep us from
implementing a better one sometime down the road.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Custom keywords, issue #890
Posted by Vlad Skvortsov <vs...@73rus.com>.
Peter Pentchev wrote:
>
>>> Oh, you mean something like that, right? :)
>>> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=112080
>>>
>>> As a matter of fact, I've updated this patch for 1.4.0, it's up at
>>> http://devel.ringlet.net/devel/subversion/
>>>
>>> And yes, I know that this is not really a good approach, and that each
>>> client binary wants to be patched (not "needs", since nothing will
>>> break, just the keywords won't be expanded), but still - it does what
>>> I need right now for my personal repository, until a better solution
>>> comes along.
>>>
>> Hey, I really like the approach! While it's not as generalized as
>> 'custom keywords', it's much simplier and seems to solve the current
>> problem.
>>
>> What is the status of the patch? Is that handed off to the patch manager?
>>
>> If my vote would count, I'd say +1 on that. :-)
>>
>
> Well, I'd suppose the patch has the same status as it had back in February
> when I first suggested something like this - an unofficial, unapproved
> patch that does the job for me, and that will probably not make it into
> Subversion itself for many reasons (and, just for the record, I do agree
> with those reasons).
>
> The main reason was, actually, mentioned in this thread - this is only
> a per-file setting, and thus has to be propset'd for each and every file
> in the source tree. Either repository-level options or inherited properties
> would be a much, much better approach - thus, this is only a temporary
> workaround.
>
The 'svn:keywords' property needs to be set on per-file basis too and it
doesn't seem to be a showstopper. As was previously discussed in this
thread, ability to automatically set properties (as iprops, repository,
or client-side settings) may be implemented as an orthogonal feature.
Having custom (or alias) keywords without that may still benefit
Subversion in many ways.
> Still, I'm glad to know that you like it :)
>
> G'luck,
> Peter
>
>
--
Vlad Skvortsov, vss@73rus.com, http://vss.73rus.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Custom keywords, issue #890
Posted by Peter Pentchev <ro...@ringlet.net>.
On Fri, Oct 20, 2006 at 12:19:36PM -0700, Vlad Skvortsov wrote:
> Peter Pentchev wrote:
>
> >Oh, you mean something like that, right? :)
> >http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=112080
> >
> >As a matter of fact, I've updated this patch for 1.4.0, it's up at
> >http://devel.ringlet.net/devel/subversion/
> >
> >And yes, I know that this is not really a good approach, and that each
> >client binary wants to be patched (not "needs", since nothing will
> >break, just the keywords won't be expanded), but still - it does what
> >I need right now for my personal repository, until a better solution
> >comes along.
>
> Hey, I really like the approach! While it's not as generalized as
> 'custom keywords', it's much simplier and seems to solve the current
> problem.
>
> What is the status of the patch? Is that handed off to the patch manager?
>
> If my vote would count, I'd say +1 on that. :-)
Well, I'd suppose the patch has the same status as it had back in February
when I first suggested something like this - an unofficial, unapproved
patch that does the job for me, and that will probably not make it into
Subversion itself for many reasons (and, just for the record, I do agree
with those reasons).
The main reason was, actually, mentioned in this thread - this is only
a per-file setting, and thus has to be propset'd for each and every file
in the source tree. Either repository-level options or inherited properties
would be a much, much better approach - thus, this is only a temporary
workaround.
Still, I'm glad to know that you like it :)
G'luck,
Peter
--
Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
I had to translate this sentence into English because I could not read the original Sanskrit.
Re: Custom keywords, issue #890
Posted by Vlad Skvortsov <vs...@73rus.com>.
Peter Pentchev wrote:
>Oh, you mean something like that, right? :)
>http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=112080
>
>As a matter of fact, I've updated this patch for 1.4.0, it's up at
>http://devel.ringlet.net/devel/subversion/
>
>And yes, I know that this is not really a good approach, and that each
>client binary wants to be patched (not "needs", since nothing will
>break, just the keywords won't be expanded), but still - it does what
>I need right now for my personal repository, until a better solution
>comes along.
>
>
Hey, I really like the approach! While it's not as generalized as
'custom keywords', it's much simplier and seems to solve the current
problem.
What is the status of the patch? Is that handed off to the patch manager?
If my vote would count, I'd say +1 on that. :-)
--
Vlad Skvortsov, vss@73rus.com, http://vss.73rus.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Custom keywords, issue #890
Posted by Peter Pentchev <ro...@ringlet.net>.
On Mon, Oct 02, 2006 at 10:36:05PM +0200, Martin Furter wrote:
>
>
> On Mon, 2 Oct 2006, Vlad Skvortsov wrote:
>
> >I still don't see a need for inherited properties here though. Given that
> >pre-commit hook ensures keywords are properly set up, this boils down to a
> >configuration problem. And why not use something as simple as:
> >
> >[autoprops-set-freebsd]
> >FreeBSD = %r
> >
> >[repository-freebsd]
> ># Any of these URLs match.
> >url = https://svn.freebsd.org/
> >url = svn://svn-freebsd.lan/
> ># ... in conjunction with any of these paths within repository.
> >path = /main
> >path = /another-subtree/project-a
> ># Use this autoprops setting for the match.
> >autoprops = autoprops-set-freebsd
> >
> >The problem here is that pre-commit hook and clients' autoprops settings
> >need to be kept in sync. The proper way to solve this for a long term
> >seems to be to configure that on server side and let clients discover the
> >settings.
> >
> >However, in the meanwhile it is possible to solve the problem at hand
> >without both iprops and "server-side autoprops".
>
> Why not extend the format of the svn:keywords property?
>
> F.ex. could a line that starts with a word followed by a '=' define and
> enable a new keyword:
>
> svn ps svn:keywords "URL Author Date
> FreeBSD=%b %r %d %a" foo.c
>
> That should be compatible with existing values of that property, and the
> property has to be set anyway.
>
> The only problem I see here is that each file can have a different format
> of for the keyword, but a pre-commit hook could check that.
>
> Just thinking out loud...
Oh, you mean something like that, right? :)
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=112080
As a matter of fact, I've updated this patch for 1.4.0, it's up at
http://devel.ringlet.net/devel/subversion/
And yes, I know that this is not really a good approach, and that each
client binary wants to be patched (not "needs", since nothing will
break, just the keywords won't be expanded), but still - it does what
I need right now for my personal repository, until a better solution
comes along.
G'luck,
Peter
--
Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
No language can express every thought unambiguously, least of all this one.
Re: Custom keywords, issue #890
Posted by Martin Furter <mf...@rola.ch>.
On Mon, 2 Oct 2006, Vlad Skvortsov wrote:
> I still don't see a need for inherited properties here though. Given that
> pre-commit hook ensures keywords are properly set up, this boils down to a
> configuration problem. And why not use something as simple as:
>
> [autoprops-set-freebsd]
> FreeBSD = %r
>
> [repository-freebsd]
> # Any of these URLs match.
> url = https://svn.freebsd.org/
> url = svn://svn-freebsd.lan/
> # ... in conjunction with any of these paths within repository.
> path = /main
> path = /another-subtree/project-a
> # Use this autoprops setting for the match.
> autoprops = autoprops-set-freebsd
>
> The problem here is that pre-commit hook and clients' autoprops settings need
> to be kept in sync. The proper way to solve this for a long term seems to be
> to configure that on server side and let clients discover the settings.
>
> However, in the meanwhile it is possible to solve the problem at hand without
> both iprops and "server-side autoprops".
Why not extend the format of the svn:keywords property?
F.ex. could a line that starts with a word followed by a '=' define and
enable a new keyword:
svn ps svn:keywords "URL Author Date
FreeBSD=%b %r %d %a" foo.c
That should be compatible with existing values of that property, and the
property has to be set anyway.
The only problem I see here is that each file can have a different format
of for the keyword, but a pre-commit hook could check that.
Just thinking out loud...
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org