Eric Gillespie <firstname.lastname@example.org> writes:
> Not quite. One of the things i thought of for the keyword format
> string was a %k specifer, which would expand to a keyword.
> Here's an example:
> # Something like this in some repo-side conf file:
> [custom keywords]
> keyword NetBSD = "%n %r %d %a"
> keyword BuildStatus = "%r %k(netbsd:build-status)"
> Set the svn:keywords property on your file to 'NetBSD
> BuildStatus' and check it in. As different versions of this file
> on different branches are auto-built, the BuildStatus will change
> (if you have your build scripts set the netbsd:build-status
> $NetBSD: foo.c 270 2002-09-02 02:23:31Z epg $
> $BuildStatus: 270 failed $
> $NetBSD: foo.c 261 2002-08-02 02:23:31Z epg $
> $BuildStatus: 261 success $
Changing the property on a file involves a commit, right? So if you
checkout, then build, you'd have to change the netbsd:build-status
property on the file, then check in the change, but at that point the
rev that you are tarballing is different from the one that passed the
build-testing (though hopefully in a trivial way).
I've been thinking of a proposal for per-revision properties that
might work better for this, though it would still need some keyword
substituting changes to solve this problem completely. I was gonna
wait till I had more substance to back it up, but the gist of it is
The idea would be to have arbitrary properties on revisions (as I
understand it, the log message is currently a property of each
revision), specified in the repo-side config file, and have the values
settable somehow at commit time (I haven't yet thought of a ui for
this that I really like) or changeable later with svnadmin, much like
the log message is now.
F'rinstance, if you set the repo to have revision properties called
'myproj:issue' and 'myproj:reviewer', you could do something like
$ svn commit -m "Fixed the problem" --set-rev-prop "myproj:issue=123" \
And subsequently someone could determine that your commit was
associated with Issue 123 and reviewed by fred without having to grep
Or, to take the case of the build-status above, if you set the
revision property 'netbsd:build-status' for the repository, you could
go back later and
$ svnadmin revpropset myrepo 261 'netbsd:build-status' 'success'
(or something; I know that really starts to get verbose...)
Unfortunately I haven't had the spare time to grovel through the
sources enough to actually try to implement this idea. If anyone else
thinks this is nifty/easy-to-implement enough to work on it, go nuts.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Sep 5 19:41:46 2002