This section is from the "Version Control with Subversion" book, by Ben Collins-Sussman, Brian W. Fitzpatrick and C. Michael Pilato. Also available from Amazon: Version Control with Subversion.
Just as Subversion uses properties to store extra information about the files, directories, and revisions that it contains, you might also find properties to be of similar use. You might find it useful to have a place close to your versioned data to hang custom metadata about that data.
Say you wish to design a web site that houses many digital photos and displays them with captions and a datestamp. Now, your set of photos is constantly changing, so you'd like to have as much of this site automated as possible. These photos can be quite large, so as is common with sites of this nature, you want to provide smaller thumbnail images to your site visitors.
Now, you can get this functionality using traditional
files. That is, you can have your
image123.jpg
and an
image123-thumbnail.jpg
side by side in a
directory. Or if you want to keep the filenames the same, you
might have your thumbnails in a different directory, such as
thumbnails/image123.jpg
. You can also
store your captions and datestamps in a similar fashion, again
separated from the original image file. But the problem here
is that your collection of files multiplies with each new
photo added to the site.
Now consider the same web site deployed in a way that
makes use of Subversion's file properties. Imagine having a
single image file, image123.jpg
, with
properties set on that file that are named
caption
, datestamp
, and
even thumbnail
. Now your working copy
directory looks much more manageable—in fact, it looks
to the casual browser like there are nothing but image files
in it. But your automation scripts know better. They know
that they can use svn (or better yet, they
can use the Subversion language bindings—see the section called “Using the APIs”) to dig out the extra
information that your site needs to display without having to
read an index file or play path manipulation games.
Custom revision properties are also frequently used. One
common such use is a property whose value contains an issue
tracker ID with which the revision is associated, perhaps
because the change made in that revision fixes a bug filed in
the tracker issue with that ID. Other uses include hanging
more friendly names on the revision—it might be hard to
remember that revision 1935 was a fully tested revision. But
if there's, say, a test-results
property on
that revision with the value all passing
,
that's meaningful information to have.