With regard to syntax checking svn:keywords.. it can already be done.
It is called hooks/pre-commit. You can use svnlook and detect mangled
syntax or other invalid settings. svn does the right thing when
faced with a keyword expansion mode it doesn't understand.
For freebsd.org, we check both in the pre-commit hook. We check
svn:keywords is correct, AND we check that you aren't mixing/matching
clients in such a way to damage the keyword tokens. (examine output
of "svnlook cat -t txn"). We use a python api script do do all the
checking at once.
Regarding custom keywords:
On Wed, Jun 25, 2008 at 4:15 AM, John Peacock
> James K. Lowden wrote:
>> 1. The keyword domain expands very slowly, if at all. CVS was around for
>> a long time with a stable list of them.
> You may have missed the 'ping' to the list just this morning about a patch
> to add a new Header keyword (that was originally submitted in March 2008).
> And you also may not recall that there were a couple of keywords added
> initially outside of CVS that relied on custom clients for a time (the *BSD
> people in particular, see below).
We added fully programmable keywords for FreeBSD.org. ("we" sounds
much better than "I". But I guess I have to take the blame for it.).
We currently take advantage of un-hacked clients not getting upset
about it. We allow free-form keyword expansion using printf-like
expansion from subst.c. I added a few extra % tokens. %P is the path
relative to the repository root, etc. This is like '$CVSHeader$' in
recent versions of cvs. For example, from our hacked svn-1.5:
# $FreeBSD: stable/7/bin/ls/Makefile 129719 2004-05-25 14:53:47Z pjd $
cvs-1.12 adds $CVSHeader$ and allows custom keywords.
>> 2. There aren't that many attributes that make sense to use in this way.
>> It's very hard to imagine the hot new keyword of 2009.
> The keyword system was rewritten some time ago in the hope that we could
> come up with a way to provide server-specific keywords (e.g. the *BSD people
> want to recreate their CVS hack to only expand their own keywords on stuff
> imported from the other streams). If we could come up with a
> server-distributed configuration file, custom keywords would be (at this
> point) relatively trivial to add without having to distribute custom
For what its worth, we've already done this. I'm sure I've got a
place reserved in hell for me, but it is done.
We currently store the expansion syntax of $FreeBSD$ in svn:keywords
on a file by file, rev by rev basis. This allows us to change the
expansion if we want to. And we probably will. Having a
non-versioned server-specified keyword config would actually be a step
backwards for us.
Our burning issues right now are:
* server-side setting of commit message templates. (we could
eliminate a HORRIFIC hack if this existed, in any form. Even a
revprop on rev 0 would be better than what we do now. The current
hack would make people cry, so I'm not showing it.)
* auto-props is way too simplistic. glob is fine, but there's no way
to specify a no-match value. I'd like to specify handling for the
three binary types that we allow in our repository, and have
everything else use a common set of properties. Yes, we check for
lurking binary sneaking in via commits. (If a file is typed as text,
but actually looks more like binary, we reject the commit). Having to
specify an exhaustive list of every extension I can think of kinda
sucks (300+ lines so far), just because I don't want keyword expansion
for gif, jpg or pdf files.
The custom keywords change was done with an eye towards submitting it.
I was inspired by the patch in the issue database, but there were a
number of serious problems with it. And I wanted something truely
FWIW, the version we're running right now is here:
Unlike some of our other hacks, this one is non invasive. It doesn't
affect svn's operation unless the features are activated via
Peter Wemm - peter_at_wemm.org; peter_at_FreeBSD.org; peter_at_yahoo-inc.com; KI6FJV
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-26 10:48:39 CEST