Tom Mollerus' Weblog

Admit it: one of the least favorite parts of our jobs as developers is coming up with time estimates for our work. Joel Spoelsky describes it this way:

Why won't developers make schedules? Two reasons. One: it's a pain in the butt. Two: nobody believes the schedule is realistic. Why go to all the trouble of working on a schedule if it's not going to be right?

If you're like me, and don't have the data available to do evidence-based scheduling, to produce estimates you basically make a guess based on past experience. And we all know how accurate those guesses are. (Usually, not very accurate at all. I worked with a project manager once who confided to me that all of the PMs at the company would take the developers' estimates and then double them to come up with what they felt was a more realistic schedule.) Sometimes I feel like it's like a serious job endeavour and more like a game of Name That Tune for software ("I can code that feature in... 6 hours, George!").

So around here at Ping Identity, we don't have to rely on time estimates so much. Instead, the engineering team has started using a metric called "Whitneys", measured on what we call the Whitney Complexity Scale. It's named after its creator, technical project director Brian Whitney.

Just a tip for those of you who, like me, have svn+ssh access to a Subversion server whose ssh port is not set to the usual value of 22: you can usually specify the port right after the server name, like so:

svn+ssh://svn.someserver.com:12345/path/to/repo

svn+ssh is a protocol that provides more security than using just svn over port 3690 or port 80, since all of your traffic will be encrypted like any other ssh communications.

Thanks to everyone who attended tonight's Boston CFUG presentation on using Subversion. If I can help anyone get set up with the server or a client, just let me know.

Wow. Between a new job with Ping Identity and attending the cf.Objective() conference, it's been at least 3 weeks since my last posting. Well, one of the things I learned at the conference came after asking a presenter for his opinion on whether there was any Subversion client for Macintosh that was worth using. The Finder plugin is a great idea, since it's like TortoiseSVN, but it's not full-featured and doesn't always show status overlays correctly; and other clients keep views of working folders and repositories in separate windows. Finally, other clients don't have a built-in diff program. The presenter didn't think that any Mac client was worth using either.

But someone from the end of my row in the audience told me to speak to him after the session was over, and he told me about Syncro SVN. It has everything you could want in a client-- an integrated view of your repositories, working directories, a great diff viewer, and session log. Plus, it has all of the features you might want, such as the ability to relocate working directories between repositories. If you're not satisfied with other Subversion clients on the Macintosh, I'd suggest you give Syncro SVN a look.

I'm a big fan of the version-tracking application Subversion (aka, SVN), as it's saved my bacon many a time. It's so easy and so helpful that I wonder why I didn't start using it sooner than two years ago.

I like SVN so much that I'll be speaking on how to use Subversion to the Boston CFUG on May 20th, 6:00pm. If you live in the Boston area, make sure to RSVP-- I'd be thrilled to see you there. Whether you're on a development team and want to avoid overwrite conflicts, or whether you're a solo developer who wants to have a record of coding changes over time, Subversion can save your bacon, too.

Today when I checked a third-party site for updates to the XSLT files I use in Microformats.cfc, I found myself wondering how I'd update the new files so that they contained the minor modifications needed for use in my component. I could have saved the new files in a separate directory, then opened each new file and compared it to my older version, making changes by hand. But I was a little worried that I'd forget to notice a change or two-- these XSLT files aren't exactly easy to read, and I only work with them once every few months. Then I remembered the ever-so-handy "diff" utility from my Subversion client, TortoiseSVN.

Just an FYI to everyone who read yesterday's post about changing the URL for your Subversion working directory when your repository is migrated to a new server: Stefan from TortoiseSVN politely informed me that I was mistaken to suggest that the "switch" function could be used to associate working directories with new URLs; instead, the "relocate" command should be used.

I might as well take this opportunity to thank Stefan and the rest of the TortoiseSVN team for not only making such a great FOSS product, but for ensuring that I don't propagate my own silly mistakes to the rest of the Internet developer community. ;)

[Editor's note: this posting has been updated to correct an inaccuracy about which Subversion function should be used to associate working directories with new URLs.]

Pete Freitag mentions a way to move a Subversion repository from one server to another server by making a dumpfile from the old repository and importing it into the new repository. I've had to accomplish the same thing, but I was faced with an extra step afterward. If you're like me, you may have some changes that you're testing in your working directory but haven't yet committed; so how do you keep those changes while reassigning your local working directory to use the new repository?

The answer is the "switch" function. Just select the top level of your working directory and run "switch" The answer is the "relocate" function. Just select the top level of your working directory and run "relocate"(which in the case of my SVN client, TortoiseSVN, means right-clicking on the working directory.) You'll see a dialog that looks something like this:

Just enter the URL for the new server, and all of your local SVN files will be updated to use the new repository. That way, you don't have to check out from the new repository and you can keep changes that you haven't yet committed.

After having this happen to me several times, I finally woke up and smelled the coffee-- I went and set up Subversion as a version-control system for all of our web files. What a lifesaver! I will never, ever do web work without saving changes to Subversion (SVN) again.

If you've never used a version control system before, I can't encourage you enough to start. There's no longer any valid excuse not to use it:

• Using version control will be too hard to do, with checking files out, checking them in, and resolving conflicts.
  That may be what it's like to use Microsoft's Visual SourceSafe product, but SVN solves all of those problems, and makes it so easy to save changes. With SVN, you check out a copy of all of the files in the project, then edit them as you wish and save changes as you wish. There are no locks-- you can save your changes any time you like. If another developer happens to have saved changes to the same file, SVN will automatically merge the changes for you. If your changes directly conflict with those of the other developer (meaning that you've changed the same lines), SVN will let you know that you need to perform the merge yourself.
  
• I'm the only developer working with these files. Why would I need version control if I can't overwrite my own changes?
  True, you can't unknowingly overwrite your own changes. But certainly there have been and will be times that you wish you could revert to an earlier version of a page that had a better layout or lacked a certain bug. Unless you're using version control, you can't get those versions back.
  
• My web site just isn't important enough to merit version control-- it's only HTML, after all.
  When Subversion is easy to use and free, there's no good reason not to use it. And there's no site that's not going to run into the issue of needing to revert to a previous version of one page or another. Even with an HTML-only site, you may want to revert to an earlier version of your design, your CSS, your HTML, or most likely, your content.