Posts Tagged 'Subversion'

Cornerstone 1.1

News from the tools front: The Greatest SCM Client EVAR, Zennaware Cornerstone, is now up to version 1.1 with a whole big whack of fixes and new features. If you weren’t convinced by my reasoning for deciding to buy version 1.0, then take a look at the much more detailed review that Jade Ohlhauser has done here — but here’s the money quote:

In my first comparison I could see the advantages that Cornerstone had to offer, but it had flaws in the workflow I needed every day. Now that those flaws have been addressed, the comparison isn’t even close. I’m going with Cornerstone. Something we can all agree on is that the competition benefits everyone. Subjectively speaking, however, it seems to me that the Cornerstone developers have made more progress in the last 4 months than the Versions team has.

As an example of that progress, let us look at a recent exchange I had with the Cornerstone author, when I got mildly annoyed at the array of projects I wasn’t actively working on at the moment taking a while to update. Note the date and time on the email I sent –

Date: October 25, 2008 6:20:13 AM PDT (CA) Subject: Support Request Is there any way to turn off the working copy refresh on an individual basis instead of globally? If there isn’t, could I please put that in as a feature request? …

– and check out how long getting it sorted took.

Date: October 25, 2008 11:15:07 AM PDT (CA) Subject: Re: Support Request Hi Alex, I have implemented per-working copy refresh configuration for 1.1 which is currently at the release candidate stage and will be released in the next two weeks.Best regards,
Simon

Now you just can’t beat service like that. If you’re using Subversion, you owe it to yourself to get Cornerstone and make life easier on yourself!

Continue Reading →
1

SVN Smackdown! Cornerstone v. Versions

Like the rest of the world, we use Subversion for revision control here at Trollwerks by choice, and for the last few years we’ve been using svnX as our client. However, it’s getting a little long in the tooth now, so when it balked at reading the repositories of a project we’d been meaning to get back to for a while, we figured we’d take a look at two new native Mac clients that everyone’s getting all excited about and see if they merited switching to: the 1.02.59 release version of Zennaware Cornerstone

and the 1.0b5 beta version of Pico+Sofa Versions.

So we start out with the repository and existing working copy of our first iPhone project. Cornerstone goes smoothly and reasonably intuitively, took a few minutes to suss out how the timeline view works but yep, it’s pretty darn nifty, nicely integrated diff implementation particularly of note.

Versions, now, first thing it says is that it’s going to muck with the metadata so that the working copy is only accessible by svn 1.5 clients. Hmmm. Well, that’s a little presumptuous, isn’t it? However, we see that the latest message on their newsgroup (point to them for having one, don’t see an equivalent for Cornerstone) reads “We made a mistake when we dropped SVN 1.4 support in beta 5 and are scrambling to correct it … This release will ship as soon as possible, before the end of this week.” OK, then, in the meantime we’ll make a copy for it to play with. That goes smoothly, and it’s got a nice appearance as well; however, the file browser seems to always display the full tree, not the selected folder, which would be rather inconvenient in some highly nested repositories we have occassion to deal with, and we’re not overly impressed that it relies on external links for its diff. OK, we would be if it knew to link to CodeWarrior, which still has The Finest Diff Implementation Ever and we just wish someone would write a standalone one as good. But they haven’t, it doesn’t, so oh well.

Next test: The repository of the project we’re getting back to, which you recall above svnX’s balking at was the reason we decided to check these out. With both, we see a sheet come up asking us if we want to accept the certificate, rather than just svnX’s failure transcript which we have to go muck around with the command line to fix; good, good. Although I’ve completely forgotten my password. Versions makes me cancel the creation completely, Cornerstone creates the bookmark anyways and asks for login/password when we try to browse it; point to them there. So we find the password, and enter it, and point them at working copies. There’s a couple new files and half a dozen modified files, so we’ll see how intuitively the two handle that. And we have some mixed results. Cornerstone; have to drill down through the folders to see the individual differences [EDIT: Option-clicking disclosure triangle to open all children usually works on the second try]; can’t see both new and modified files at the same time [EDIT: The 'Changed' selector includes both]. Somewhat annoying. On the plus side, when we hit unselected commit, which is what we’ll usually be doing, it pops up a sheet to insist that we deal with the unversioned files before proceeding; nice safety net, that. Versions; displays all unversioned and modified at once when Changed toggle is selected, much better; but commit just brings up the modified files, it ignores the unversioned files completely. Having run into a few instances in the past where forgetting to add a new file caused problems later on because contrary to our complacent assumptions the checkin in question wasn’t actually compilable, we’ll give Cornerstone a massive bonus for its valiant efforts to save us from our own stupidity. Finally, let’s see how we handle files we want to exclude, like Xcode’s build folders and .pbxuser files. With Cornerstone, we right-click, select ‘Ignore’, and they’re gone (once we commit, apparently the properties are a repository change). With Versions, there does not appear to be any way to set a permanent exclusion, despite the website’s claim “Working Copy Browse View: Set svn:ignore and other properties.” Well, if it’s there, it should be more obvious.

Verdict: Despite a couple minor interface quibbles, Cornerstone is definitely the better client; however, both are massive improvements over svnX. So, let us turn to cost. svnX is free and open source (although the server seems to be down presently), massive points in its favor; Versions is currently unpriced but the beta is time-limited; Cornerstone is $59 which might strike one as a little steep for a GUI front end, but hey, soon as it saves us an hour of working time it’s paid for itself, right? And there is a two-week free trial, so we’ll give it that, and when that expires, just to be completely evenhanded we’ll spend another two weeks with whatever the version of Versions (heh) is to give it a shot, and whichever ends up being more stable and workflow streamlining in practice, we’ll move to that we figure. If we end up with a conclusion that’s different than our initial impression that Cornerstone is superior enough to be worth the asking price, we’ll be sure to let you know!

Continue Reading →
20

Issue tracking: Lighthouse Keeper

So, now that our first native iPhone app is off to beta testing (and that took quite long enough, didn’t it?) time to sort out what we’re going to do to formalize the issue tracking here at Trollwerks, which in the programming frenzy since our April inception has been … transcriptive, shall we say? … before any external issues become arisen.

We’re not really looking for much in the way of process here (at the moment, anyways) only personal organization, so our feature checklist is, oh look at that, empty. Unless you count ‘as low overhead as possible’ as a feature. But it’s more of a philosophy, really. One we strive to in every area of life, actually; after all, the one and only resource that’s truly finite is time. But we digress. (Oh, the irony!) So, getting back on track, what would low overhead imply for Our Perfect Issue Tracker?

First off, it implies no ongoing cost without clearly compelling justification. So we take your FogBugz and your JIRA and your whatever commercial offerings, and we summarily eliminate all of those, since there is no clearly compelling justification on the horizon.

Second off, it implies that we’re not going to be setting up and managing our own server if at all possible, because that’s a hassle. We’ve tried both local and remote setups of that at various places, and at the very best it’s been only intermittently annoying. So we take your Bugzilla and your Mantis and your whatever open source offerings, and we summarily eliminate all of those. Are we Linux geeks? We think not!

So that reduces our problem space immensely … since it gets rid of all widely used alternatives. Hmmm. Well, let’s look at it the other way then, what do we like in an issue tracker? And, y’know, there’s only one thing we’ve ever used that springs to mind; and that’s over ten years ago now, the Mac OS 7 native program “TestTrack”, which has grown up to become a real company since; but has completely lost the elegance and simplicity of a native Mac application with a single data file. (Multi-user control was “file locking.” Not the most scalable no, but very low overhead indeed!) We liked using that, and we haven’t liked any of the client-server systems we’ve used since.

Well, guess what? It’s not here now, but it’s promised that soon there’ll be a native app that looks like it has a good shot at displacing our pining for old school TestTrack. It’s called Lighthouse Keeper, and if there has ever been an issue tracking client that’s looked as good as this, we’ve certainly never heard of it:

So what is the “Lighthouse” that this is the Keeper of? We’d never heard of that one before. Turns out that it’s a hosted service that focuses on

well, beauty and simplicity, as they say. Now that sounds about right. As does what the Keeper author has to say:

I looked at the usual suspects: Trac, FogBugz, Mantis, Jira etc. None of them really clicked with me, they seemed to do too much or have overly complicated UIs. Lighthouse was different, it was designed to be simple. It didn’t try to be everything to everyone like some of the above. It let you file tickets, assign them to someone and then work your way through them. And most of all, it had an incredibly well designed UI.

Of course, I’m not exactly the biggest fan of web apps. They’re fine to use occasionally, but when it’s something you’re working with all day it’s frustrating to either have to keep logging in, or at least keep a Safari window open. Luckily the Lighthouse developers provided a pretty comprehensive API so I thought that I’d set about making a desktop client to get around this.

So that’s all looking pretty intriguing, and we thought we’d take a look at just what the Lighthouse pricing is, on the off chance that this might rise to the level of “clearly compelling justification” that we mentioned earlier. And guess what? They do have a free offering, not only for Open Source projects, but for private use as well, with restrictions that most likely aren’t going to chafe us in the near future. And hey, you just can’t get any lower overhead than a hosted service, can you now?

So there we are! A new issue tracking system to try out, which we’d thoroughly recommend to your attention as well if you subscribe to the same minimalist aesthetic we do. Once Lighthouse Keeper makes its way onto our desktop, we’ll be sure and let you know how this experiment progresses!

UPDATES:

While we still like Lighthouse, if you’re looking for a self-hosted bug tracking system, Bugify sure looks sweet!

17 Bug and Issue Tracking Apps for Developers

Continue Reading →
4