Some of you might have noticed that this blog was unavailable for a few hours on Tuesday July 23rd. There was a power outage at the Typepad datacenter (actually a big chunk of San Francisco was out of power). None the CollabNet-run servers were affected (they are elsewhere and on back-up power).

At the time of this writing, this is the latest info from Typepad (5.23pm):

"We are now bringing the application back online. You may experience intermittent performance while we restore the application. Readers may experience issues commenting."

Sorry for the inconvenience.

If you are a regular reader of this blog then you are undoubtedly aware that Subversion 1.5 will be coming out later this year and that the big feature is merge tracking. Technically, merge tracking is a largely internal feature with the exception of the ways in which it simplifies the overall UI of the merge process. Implementing this feature has caused us to spend a lot of time just thinking about the entire merge process and this has led to some additional improvements that are not technically part of the merge tracking feature. That brings us to what this post is about and that is how Subversion 1.5 will make it easier than ever for you to resolve conflicts.

We all make mistakes. Wouldn't it be great if life always gave you a second chance or an opportunity to correct those mistakes? Fortunately when you are using Subversion you can always correct a mistake, in most cases, you can correct those mistakes quite easily.

Here at CollabNet, we get a fairly constant stream of questions about Subversion from a wide variety of folks and via several different communication vehicles (webinar participation, training sessions, and so on). We try to answer them all as quickly as possible, but sometimes we wind up with a backlog of unanswered questions. So, as has been done on this blog before, I'll try to answer some of those queued up questions, focusing this time on questions related to Subversion's locking feature.

One quality of a typical engineer is a heightened sensitivity to potential problem areas. For software engineers, that often means spotting possible bugs in our peripheral vision while working on some nearby chunk of source code. This is both a blessing and curse. You want your bugs fixed, but unfortunately we sometimes get derailed from our primary task by these little excursions into Perfection.

Another fact of a developer's life is that there are always more things to work on than time to do so. And everything is of the utmost priority to someone. And so here again, we find ourselves working on multiple things at the same time, making slow-yet-incremental progress on each of them so at least we can say about them all with a clear conscience and a forced smile, "As it turns out, I'm working on that right now."

To my managerial readers, I regretfully admit that I have absolutely no solution for those problems. After all, this is a technical blog. But I can (and will) tell you about an upcoming Subversion feature that might reduce the context-switching costs for those developers: changelists.