It’s got a good deal of the functionality I want.
• I can see the state of the files in my working copy: modified, added, removed.
• It supports visual diffs, and for extra points, it supports all the major external apps that provide this.
• For a repository, it can show me all the files affected by a particular check-in. It supports deleting, moving, and copying files in the repository.
All in all, it’s a workable replacement for Xcode’s Subversion support. That’s how I use it, as an occasional replacement, to deal with the Subversion work I need done for files that aren’t in my Xcode project.
Now, before I get to what I don’t like about it, let me acknowledge two things.
One, svnX has been released under the GPL. I could dive into the code myself and fix the problems I’m going to describe. Unfortunately, I’m already in the middle of a project – that’s what I’m keeping in my Subversion repository, and why I need a Subversion client! That said, I may take this up at some point.
Two, I want to keep my criticism of the application separate from the application authors. I treat the failings of a project like this, done for free and presumably in one’s spare time, far differently than I would treat even a shareware application.
I said svnX had most of the functionality I need. But in the realm of polish, it is disappointing, shocking even.
Have a look at the screenshot of the repository window. Notice anything strange in the uppermost table? What’s that first column of radio buttons doing there? To do a diff between two check-in versions, I shit you not, you need to select one of them via the radio button column, and the other by a more normal selection highlight, and then click the FileMerge button.
Why is the UI set up in this bizarre manner? I don’t know for sure, but my suspicion is because it was easier. In Cocoa nibs, tables can be set to allow only single-row selection, or multiple-row selection. Multiple-row selection, as you can imagine, involves a lot more work to handle all the different possibilities. But it’s what users expect.
Actually, I simplified things a bit. Hitting the FileMerge button doesn’t go directly to a file merge. It actually brings up a sheet with exactly the same two tables that are at the top of the window the sheet is attached to, from which you have to select the versions you want to compare. What does that sheet refer to? It turns out, it refers to the file selected in the third table on the main window, though the sheet gives you no indication of that. You can’t multiple-select in that file table, either, so you can’t do several file comparisons at once.
svnX has separate windows for Subversion repositories versus Subversion working copies. You can see a screenshot of the working copies window here. You’ll notice this window is much more simple. The repository history is completely unavailable. All you can know from this window is whether any files have had changes made to them since the last check-in.
Again, I’m assuming the reason this was done was to make things easier. It would be much harder to create an intuitive user interface where the information about a working copy is overlaid on the repository itself…but that’s what I want.
I want to be able to compare my working copy file’s condition against what was checked in 10 revisions ago. I want to be able to see what check-ins were made on the files that I have edited, in the same table – a column you can hide, perhaps, so it’s not always cluttering up the window?
I want to be able to perform file and folder moves in the working repository before checking them in: right now, you can only do that in svnX in the repository window, where changes are immediate.
I want to be able to go from the row representing the file to the file in the Finder. Contextual menus seem totally unsupported.
There’s probably more, but this will do. Some of this stuff is small potatoes, but if I were to work on this, I’d want to tackle the big stuff first, which would probably mean rewriting a lot of the UI code. Not something to be undertaken lightly.
Before I go, I’m going to have to take issue with the name. “svnX”? You name a GUI application after Subversion’s crypticly-named command-line tool plus an “X” to show it’s on Mac OS X? Is that the best you can do?
Here are a few suggestions, marked as (taken) if I found an app with that name in http://VersionTracker.com:
“Subversion” sounds like “Subversive”, right? So how about: Saboteur (probably not), Instigator, Agitator, Provocateur (I like that one).
You’re gaining access to an otherwise unreachable destination, like a castle, right? So how about: Drawbridge, Bridge, even Moat.
It’s a record of changes, so how about: History (taken), Historian (taken), or Archiver. You use it to find or figure things out, so maybe: (Code) Detective, Codehound, maybe even Code Thief.
Finally, I’ll end on a positive note: I like the swirly blue icon.