Enterprise SCM Techniques with Xcode and Subversion

Actually that title is a bit of an oxymoron, whilst Xcode can be used in the enterprise with SCM systems like Subversion (SVN), there are some things that Xcode refuses to do properly one of them being honouring SVN file locks.

SVN file locks allows you to mark files that should not be edited concurrently via the svn:needs-lock attribute.  Examples of files that you should really apply this to are:

• *.XIB files
• *.StoryBoard files

Now Xcode will see the SVN attribute and prompt you if you wish to “unlock” it.  It appears however that whatever Xcode is doing, it certainly is not informing the SVN server about SVN locks as other members in my team can perform the same action, even on Windows leading to false assumptions over file integrity.  Regardless of the OS, this passive lock breaks all user workflows if they attempt to check in the file due to a SVN error.

Solution

So what can be done about it?  We have a few options:

1. Use SVN command-line tools in Terminal
2. JetBrains AppCode – full alternative to Xcode (minus IB) + SVN client
3. Zennaware Cornerstone
4. Black Pixel Versions

Any of the above tools fully honour SVN needs:lock for concurrent users on multiple machines and platforms.

Give Subversion the Flick–Move to Git!

After using Subversion (SVN) for a little while now I think it is time to move on because much of the people I know including myself tire of SVN’s inability to accommodate contemporary enterprise software development. Branching?  Distributed development anyone?

Enter Git – something that seems to be able to handle both of these important concepts quite well. Unlike SVN, Git has no “central server”, in fact it is better to think of Git as being “peer-to-peer”. Git may be a bit more tricky to use but then again so was the move from SourceSafe to Subversion or even xcopy to SourceSafe.  Feature and performance wise it seems both Git and Mercurial are in a league of their own leaving SCMs like SVN and CVS in the dust.  However the latter uses Perl scripts which makes one wonder about the robustness of the project. 

TortoiseSVN users will feel right at home with TortoiseGit – a Windows Shell extension; and for Visual Studio 2010 there is a Git Source Control Provider which you can download via the Extensions Library in VS.  TortiseGit “wraps-up” the command-line interface that is in Git – something which I do respect and can see possible automation using batch files or Windows PowerShell.

There is free Git hosting here which seems reasonable.  I particularly liked the Next Steps summary screen that appears after you create a project – rather helpful when learning Git.

All commits can be securely signed by the author which is nice in this day and age.

Sergio Pereira has written up a rather nice post to explain client setup here.  Well done!