Revision-global properties?

Hi all,

A quick question about something which I suspect is against the
Subversion philosophy - but I wanted to ask in case I'm missing
something. My apologies for being a bit verbose: the situation
is mildly convoluted.

My company uses Subversion to manage a software development tree.
A recent policy change dictated that check-in emails (which we'd
been sending manually to explain the justification and background
for each change) should be pasted verbatim into the log for that
check-in. Leaving aside the question of whether this is a good
idea (it made the log impossible to scan as a summary of changes),
an even more recent policy change dictated that the check-in
process would automatically generate the check-in email from the
log message.

This has resulted in the stripping of all formatting information
from check-in messages, but has left me with a more pressing
dilemma: I've been known to include diagrams of what my code
does in the check-in email, and this is now impossible. Such
images are specific to the changes in the check-in, not the
general state of the tree, so I don't really want them cluttering
up the tree proper. I can't just check them in as normal files,
because most people don't know or need to know about them (but if
the tree is checked out then they'll take up space anyway), they
may well get out of date after later check-ins (while correct for
their check-in, later changes shouldn't need to worry about them)
and so on; I really want a way of associating them with the
check-in and nothing else. I also don't really want to double
up on check-ins by checking the images in and then deleting them
immediately, which is the simplest option.

One solution is to generate a secondary tree in the repository
which explicitly contains images for those check-ins, but is
outside the tree which is usually checked out; people would then
be able to access them directly when needed, and they'd be
accessible via the web interface to our Subversion server.
The obvious thing to do is to create a directory with the same
revision number as the check-in and put the images in it (e.g.
svn/sw_checkin_images/2109/foo.gif), and include references to
the URL for accessing this image in the log file. There's a minor
issue that I don't know the revision number (definitively) until
the check-in has happened, and therefore I can't check in the
directory with the images until after the primary check-in, because
I won't know its name. I can correct the link in the log message by
using svn propset --revprop after the check-in, but this will be
too late for our automated email process - which is a pain. I could
describe the first check-in, with images, in the second, but that
loses the association between the check-in mail and the changes.
It's also a bit ugly to double-up the number of check-ins, and to
have to create a secondary tree in the first place.

To summarise the process, since that's a bit wordy:
1) Commit code into svn/sw (get revision number)
[Automated check-in mail goes out at this stage, sans images.]
2) Create svn/sw_checkin_images/[revision number]/ and add images
3) Commit the images (and get their URL on the svn web interface)
4) Update the log for the original check-in to point at them

Not really ideal.

Another option is to create custom revision properties which
contain the images. This saves the need to create a spare tree
and means that the images get exclusively associated with the
right check-in, but means:
1) Pointing a URL at the properties for inlining in the check-in
email may be awkward (there doesn't seem to be an obvious way to
get at properties via the web interface), and
2) Because the properties are per-file, rather than global for
the revision, the images would be copied (at least on the repository)
for every file changed in the check-in - which is inefficient.

It may be possible to get around the first problem; so long as
the email contains correct information about how to get at the
image (unlike the first suggestion) I'm not so bothered about
whether the images are in-lined anyway. The latter problem is
annoying, though, even if it's not all that likely to bring the
server to its knees (since I've been emailing them around, the
images I produce tend to be small). I'd like to do it right, though:

QUESTION: Is there some way of indicating to Subversion that a
revision property is the *same* for multiple files? I don't know
whether the Subversion database is intelligent enough to notice
the duplication for itself (and it may need to, since presumably
someone could later update the revision property on a subset of the
files); if it *is* this intelligent, then my worries may be for naught,
and this may be my way forward. I'm also assuming there's no concept
of a meta-property which I could use to indicate that a given custom
property contains, e.g., a PNG file - although I doubt this will cause
too much confusion if I call the property "foo.png".

The other solution, of course, is a lot of ASCII art and crossed
fingers that nobody will be using a proportional font in their
email package. That's kind of a last resort, though.

If it's not possible for Subversion to share revision properties,
does anyone have an alternative cunning plan which might be able to
help me?

Thanks in advance,

-- 
Andrew Garrard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org