On Dec 5, 2007, at 14:57, subversion@fluppet.demon.co.uk wrote:
> 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.
> an even more recent policy change dictated that the check-in
> process would automatically generate the check-in email from the
> log message.
> I've been known to include diagrams of what my code
> does in the check-in email, and this is now impossible.
> Another option is to create custom revision properties which
> contain the images.
This is what I was going to suggest.
> 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
The mod_dav_svn web interface provides no way to see any properties,
as far as I know. You'd have to use another web interface or write
your own, if seeing the image in a web browser is imperative.
> 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.
*versioned* properties are per-file. *revision* (*unversioned*)
properties are per-revision (not per-file).
> 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.
Well, the problem is that there is also no way to attach your image
as a revision property until after you do the commit. So the mail
could only say "check here to see if there are any images for this
commit" which is kinda crappy.
Could you convince management to allow the commit mails to be delayed
by 5 or 10 minutes? That would give you time to attach the image and
have it included in the mail. It would also give anyone an
opportunity to fix silly typos in their commit messages. Happens to
me all the time that I commit something, then realize I typod the
commit message and have to fix it.
> 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.
As above, revision properties apply to the entire revision. They are
not attached to specific files.
> 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".
There's no meta-property. You could have two properties: one, the
commit-image and one the commit-image-mime-type. Or the second
property could be commit-image-name and based on the extension of the
name you could figure out what type of image it is. Or you could just
have a single property containing the binary data of the image and
programmatically figure out what type of image it is. (There's the
unix "file" command which can do that for files, for example, or the
PHP function getimagesize() which gets not only the image size but
also other information about it, including its format.)
> 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?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Dec 5 22:23:41 2007