[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Custom keywords, issue #890

From: Martin Furter <mf_at_rola.ch>
Date: 2006-10-02 22:36:05 CEST

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
Received on Mon Oct 2 22:36:23 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.