Core Intuition: Traveling Luddites
June 5th, 2008Manton and I recorded another episode this week, just in time to hopefully give you a little something extra to listen to on the way to WWDC, if that’s where the winds are taking you.
In this episode we talk a bit about travel and how we keep up on our indie business commitments on the road. We also chat about the recently updated book from Aaron Hillegass: Cocoa Programming for Mac OS X. Manton bought a copy but I apparently think I’m too good for programming books.
Finally we touch on the question of distributed source control systems, such as git, mercurial, and bazaar, and whether we should be switching to them or sticking with trusty Subversion.
Enjoy!
June 5th, 2008 at 11:43 pm
Great podcast. I’m currently using Mercurial for version control. DVC is great for quick branching/merging. Out of curiosity, how do you guys handle branching and merging NIB/XIB files?
June 5th, 2008 at 11:51 pm
Heh. Very carefully. :)
Merging or even diffing nib changes sucks. So I always try to be disciplined and remember to check in ASAP when I make any substantive change. It does raise a good question though, about how a distributed system might make for a tougher merge when nib changes come back into the mainline. I guess I’ll have to see how that goes. At least, though, with the offline commits you can annotate the changes with comments as you go.
June 6th, 2008 at 7:21 am
Hi Daniel, I’m not usually a big podcast fan, but the topics were so freakin’ timely for me I had to listen in. A few things:
1) You rely on mail filters only existing on your ‘base’ mac? Holy cow, is it 2001 again?? I personally moved all my domains to Google Apps and couldn’t be happier (but admittedly it’s not for everyone).
2) Considering your audience, it was probably a bit overkill to explain what ‘source control’ is. ;-)
3) I’ve also been looking into switching to Git, etc. Unfortunately I simply don’t have the time now for looking deeper into it, so it was great to hear opinions of devs in a similar position to myself. While I’m stuck with Subversion, will you please answer one question: How the heck do you update an embedded framework (ie. Sparkle) in your SVN project? Do you delete and add? Or filemerge the bundles? What a PITA bundles + .svn folders are.
Anyways, sorry about the huge comment, but thanks to you both for the podcast… it was a great listen.
June 6th, 2008 at 8:52 am
Hi Jeff! Glad the topics were up your alley.
I think the reason I felt compelled to explain source control is we’re not really sure yet who our audience is. I know we have a lot of less technical people tuning in for the “taste of developer life,” and I don’t want to marginalize them too much :) We’ll see how things evolve though, maybe it will turn out to be a more technical podcast than we were necessarily anticipating.
For the annoying subversion situation of updating binaries, I do tend to just merge the bundles, when necessary. The ditto command line tool is handy for this, because you can use it to “spray” the contents of one folder over another, without obliterating the .svn folders in the target.
In general though I try to avoid this situation by not, for instance, checking in binary frameworks to my source bases. I know it’s unavoidable in cases where for instance a licensed library is distributed only as a binary. But for the Sparkle case in particular, I use an Xcode project dependency, so that Sparkle’s framework is built from source every time and then copied into the project. No binaries in any source trees.
Daniel
June 6th, 2008 at 9:33 am
Yeah, good point about your audience. I didn’t really mind it of course, it was short and sweet, just kinda felt like the ubiquitous ‘screeching record at the party’ scene. :D
Thanks for the tip about ditto, I’ll take a look at that. I know a lot of developers prefer to go the whole ‘project linking’ route. I’ve never liked that approach for 3rd party libs, even if they are open source. Just feels wrong. Yes I have the sources, but I still want to treat it like a black box if possible. It also ruins my ‘ideal’ of an encapsulated (check-out and build) project. I find it fascinating that all developers are incredibly anal about certain things, just not always the same things. Thanks for sharing!
June 6th, 2008 at 3:23 pm
Hey Jeff,
if you’re not tied to using Git, there’s a plugin that lets Bazaar check-out from and commit to Subversion repositories that might interest you. The name of it is bzr-svn, and you can find more information here.
June 7th, 2008 at 11:02 am
The podcast is brilliant, relaxed and informal as the best radio features, Keep up the good work,
Davide
June 7th, 2008 at 12:19 pm
I agree with Daniel re NIB commits (and pbxproj, for that matter); the only way to do it is very carefully. If you can avoid having multiple people working on the same NIB file[*], then you can keep merges to a minimum. I have encountered some merges where I’ve just given up, reverted the changes to the base version and manually re-made the changes that were implied in the commits :-(.
[*]if you can’t avoid having multiple people working on the same NIB, then does that one NIB manage too many unrelated components? The one place that question fails to suggest a resolution is, of course, MainMenu.nib :-(.