Reverting to a previous revision with Subversion

One of the great advantages of using a version control system to manage source code is that you never lose the history of changes to your software project.  You can always see what a file looked like at any point in the past.  Sometimes, you need to take this a step further and actually revert a file (or files) back to an earlier version.

Taking a file back in time is only rarely necessary (in my experience, anyway – I suppose it depends on how a project is managed).  As a result, it is one of those things that I always forget how to do by the next time I need to do it.  So, this is a short post discussing how to achieve this with Subversion.

First, what about the Subversion command svn revert?  To avoid any confusion:  This command simply reverts any local changes (i.e., uncommitted changes) to a working copy of one or more files.  Thus, it does not make any changes to the repository and therefore does not do what we need.

The key to reverting a file to a previous revision is the svn merge command.  The general idea is to do what is known as a "reverse merge."  In a nutshell, you tell svn merge to make your local working copy look like a previous revision, then use svn commit to send these changes to the repository.

Suppose that the latest revision of a project is 270, and we need to roll all of the files in some directory back to revision 240.  Here is the merge command to do this.

svn merge -r 270:241 https://repository.location/path/to/directory

The key is the argument "-r 270:241", where we specify the two revisions to compare.  Here, we're finding the differences between the latest revision, 270, (the "left side" of the comparison) and revision 241 (the "right side" of the comparison), and then applying the differences to the local working copy (assumed to be the local current directory in this form of the command).

If the merge is successful, then svn commit can be used to make the changes official, and you're done.

The additional argument "--dry-run" is also useful to know.  By adding this to the end of the svn merge command, you can see a summary of what changes svn merge would make without actually altering any local files.  Of course, if you do the merge and then decide you made a mistake, you can simply run svn revert to undo the changes to your working copy.

For more details, see the section "Advanced Merging" in the official SVN book, Version Control with Subversion.

Getting the total shutter actuation count from a Canon DSLR

Given enough use, the shutter mechanism on digital SLR cameras (or any camera with a shutter) will eventually fail.  How many pictures can you take before that happens?  Browsing the data at the Camera Shutter Life Database suggests that the actual number of actuations prior to camera death is highly variable, but you should expect tens of thousands, upward to one hundred thousand or more photos out of most DSLRs.

As far as I know, all DSLR cameras keep an internal count of their total number of shutter actuations.   This number can be of interest to the camera owner for a variety of reasons.  Perhaps you're just curious how many photos you've taken since you acquired a camera.  Or maybe you'd like to see if your camera is reaching its life expectancy and it might be time to look for a replacement.  If you are shopping for a used camera body, the shutter actuation count is a bit like the mileage on a used car – it gives you a sense for how heavily the camera has been used.

Recently, I was curious about how to get this information out of a Canon DSLR body.  I discovered that there is a lot of conflicting, and sometimes flat-out wrong, information about this floating around on the Web.  So when I found a working solution, I thought it'd be worth sharing.  Now, if you have a Nikon DSLR, getting the shutter actuation count is easy.  Nikon cameras are nice enough to add this information to the EXIF data of every JPEG image they generate.  All you have to do is inspect the EXIF data!

Despite numerous postings online claiming that Canon cameras also do this, they do not (at least, none that I know of).  With some searching, you can find links to several freeware programs (mostly Windows-only) or websites that claim to be able to extract this information from Canon cameras.  I haven't tried any of them, though, because once again, GNU/Linux and open-source software came to the rescue with an incredibly simple solution.  I must acknowledge this forum thread because it pointed me to the solution I'll describe below.

First, you need to have the program gphoto2 installed.  If you run Debian or a Debian-based Linux distribution, such as Ubuntu, installing gphoto2 is as simple as opening a terminal window and running this command.

sudo apt-get install gphoto2

Then, connect your camera to your computer's USB port and turn on the camera.  Back at the terminal window, run this command.

gphoto2 --get-config /main/status/shuttercounter

If everything worked correctly, you should get output similar to the following.

Label: Shutter Counter                                
Type: TEXT
Current: 11892

The number at the end is the total number of shutter actuations. It couldn't be much easier than that!

Using Java and the Jersey library to process multipart/form-data with "arrays" of form elements

Yes, that title is a mouthful, but I couldn't think of a more succinct way to describe the problem.  Sometimes, it's very useful to create an HTML form that contains multiple input elements with the same name.  Then, on the server, you would like to be able to treat the values of these elements as an array.  This is generally fairly straightforward in most server-side programming languages, including Java with the Jersey library (a standard way to build RESTful Web services in Java).  However, if your form data are encoded as "multipart/form-data," (the norm for file uploads) then it turns out that achieving the desired functionality using Java and Jersey is not as straightforward as you might think.  Perhaps I didn't search in the right places, but I found relatively little helpful information on the Web (and some folks simply concluded it wasn't possible!).  So, here is one working solution to the problem, and I hope this might save someone else the time that I wasted figuring this out.

To illustrate the problem, suppose you need to process form data that include a file upload along with some other information, perhaps a keyword designation for the file.  Your HTML <form> element might look something like this.

<form id="upload" enctype="multipart/form-data" method="post" action="upload">
    Keyword: <input name="keyword" /><br />
    File:<br/>
    <input type="file" name="file" size="44"/><br/>
    <input type="submit" value="Upload file" /><br />
</form>

And the (simplified) Java code you use to handle the form data might look like this.

@POST
@Path("upload")
@Consumes(MediaType.MULTIPART_FORM_DATA)
public DataFile upload(
    @FormDataParam("keyword") String keyword,
    @FormDataParam("file") InputStream file_in,
    @FormDataParam("file") FormDataContentDisposition contentdisp)
    throws Exception {

    // Do something with the form data... 
}

That should all work fine, but what if you want to let users provide an arbitrary number of keywords, using a separate input box for each keyword?  You could write some javascript to allow the user to click a "more keywords" button that adds more input boxes to the form.  Then, your form would effectively look something like the following.

<form id="upload" enctype="multipart/form-data" method="post" action="upload">
    Keyword: <input name="keywords" /><br />
    Keyword: <input name="keywords" /><br />
    Keyword: <input name="keywords" /><br />
    <!-- Could be any number of keyword elements here... -->
    File:<br/>
    <input type="file" name="file" size="44"/><br/>
    <input type="submit" value="Upload file" /><br />
</form>

How should you handle this on the server side?  The obvious solution is to specify a parameter that is a List, like this.

@POST
@Path("upload")
@Consumes(MediaType.MULTIPART_FORM_DATA)
public DataFile upload(
    @FormDataParam("keywords") List<String> keywords,
    @FormDataParam("file") InputStream file_in,
    @FormDataParam("file") FormDataContentDisposition contentdisp)
    throws Exception {

    // Do something with the form data... 
}

Unfortunately, this straightforward approach doesn't work for MediaType.MULTIPART_FORM_DATA, even though it works fine for other media types.  The trick is to replace the "keywords" parameter with a List of FormDataBodyPart objects.  Then, we can extract the keyword String from each FormDataBodyPart.  In the following example, the extracted keyword strings are placed into another List.

@POST
@Path("upload")
@Consumes(MediaType.MULTIPART_FORM_DATA)
public DataFile upload(
    @FormDataParam("keywords") List<FormDataBodyPart> bparts,
    @FormDataParam("file") InputStream file_in,
    @FormDataParam("file") FormDataContentDisposition contentdisp)
    throws Exception {
    // Get the keyword strings.
    ArrayList<String> keywords = new ArrayList<String>(); 
    for (FormDataBodyPart bpart : keywords)
        keywords.add(bpart.getValueAs(String.class));

    // Do something with the form data... 
}

And that should work.  It's a bit awkward, but still a fairly simple solution.  Finally, I must acknowledge these two threads, which provided the clues I needed to figure this out.