Cheers for the feedback, Ryan.
subversion-2007b@ryandesign.com wrote:
>
> On Dec 5, 2007, at 14:57, subversion@fluppet.demon.co.uk wrote:
>
> > Another option is to create custom revision properties which
> > contain the images.
>
> This is what I was going to suggest.
It feels like the right solution - at least within the constraints
of "right" which are being imposed on me. :-)
> > 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.
It's actually less vital that I can use the web interface than that
there's a sensible place to put the images which can be accessed by
anyone who needs them, without version number confusion. Including
an appropriate "svn propget" command line in the check-in mail isn't
quite as nice as inlining, but I'd live with it - anyone who cares
enough to read the email can cut and paste. Nice to know that I'm not
being thick about the web interface, though (and I'm sure I could
knock up a couple of lines of CGI script).
> > 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).
Ooh! a) That solves my problem, and b) I feel stupid now. Thanks. :-)
> > 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.
Not necessarily - I'm not talking about pasting the content of the
property into the check-in mail, just a link to it. By the time
anyone tries to read it, I can have the image(s) in place.
> 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.
I could ask; the mail system is hanging off the RSS feed, because
the guy who enabled it didn't want to mess with change hooks, so
there ought to be something that can be done. The old system (manually
sending the check-in mail and log separately) involved manually
typing the revision number at a given point in the email/log - so
the emails often went out long enough after the check-in for me to
have updated the number (to allow for someone having got in with a
change since my last svn update and not bother to send an email)
and do an svn propset --revprop anyway.
> As above, revision properties apply to the entire revision. They are
> not attached to specific files.
Cheers; good news.
> > 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.)
I'll probably just rely on "file" and/or extensions - just nice to
know that I'm doing it right!
Thanks again,
--
Andrew Garrard
---------------------------------------------------------------------
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:58:21 2007