Eric Gillespie <epg@pretzelnet.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
> property).
>
> /*
> $NetBSD: foo.c 270 2002-09-02 02:23:31Z epg $
> $BuildStatus: 270 failed $
> */
>
> or
>
> /*
> $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
thus:
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" \
--set-rev-prop "myproj:reviewer=fred"
And subsequently someone could determine that your commit was
associated with Issue 123 and reviewed by fred without having to grep
through logs.
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.
Cheers,
-B.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 5 19:41:46 2002