On 10/2/06, Vlad Skvortsov <email@example.com> wrote:
> Garrett Rooney wrote:
> > On 9/28/06, Vlad Skvortsov <firstname.lastname@example.org> 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:
> FreeBSD = %r
> # 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.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Oct 2 22:38:23 2006