views:

396

answers:

2

So you know a lot of Mac apps use "bundles": It looks like a single file to your application, but it's actually a folder with many files inside.

For a version control system to handle this, it needs to:

  • check out all the files in a directory, so the app can modify them as necessary
  • at checkin,
    • commit files which have been modified
    • add new files which the application has created
    • mark as deleted files which are no longer there (since the app deleted them)
    • manage this as one atomic change

Any ideas on the best way to handle this with existing version control systems? Are any of the versioning systems more adept in this area?

+2  A: 

Mercurial in particular versions based on file, not directory structure. Therefore, your working tree, which is a fully-fledged repository, doesn't spit out .svn folders at each level.

It also means that a directory that is replaced, like an Application or other Bundle, will still find it's contents with particular file names under revision control. File names are monitored, not inodes or anything fancy like that!

Obviously, if a new file is added to the Bundle, you'll need to explicitly add this to your repository. Similarly, removing a file from a Bundle should be done with an 'hg rm'.

There aren't any decent Mercurial GUIs for OS X yet, but if all you do is add/commit/merge, it isn't that hard to use a command line.

Matthew Schinckel
+1  A: 

For distributed SCM systems like git and mercurial shouldn't be a problem as Matthew mentioned.

If you need to use a centralized SCM like Subversion or CVS, then you can zip up (archive) your bundles before checking them into source control. This can be painful and takes an extra step. There is a good blog post about this at Tapestry Central:

Mac OS X bundles vs. Subversion

This article demonstrates a ruby script that manages the archiving for you.

Nick Haddad