Tagging, releasing, comparative differential of versions and collaborative features of SVN or CVS.

This is what most need from version control…

While timemachine is an amazingly useful , yet simple, backup system that snapshots, this only has value for single user environments ( like my laptop !! ).

For example jump into timemachine now and find the pages document before you removed the word “elephant” on line 3 of paragraph 4.

Maybe I am missing something but I view timemachine as a backup system with file recovery, not a versioning system per say.

http://www.symonty.org/iWorkPatches/

I’m not a Fink or MacPorts user, but I believe either should install hg or git for you easily enough. As for GUIs, the best I can offer is the discussion of TextMate support for both hg and git; BBEdit or TextWranger may also support one or both as well. Finally, git does ship with its own GUI, of sorts, called gitk (git + Tk) that may be of help to you.

I’m glad you’ve found this post and ensuing discussion beneficial! That’s what we strive for at The Apple Blog.

After thinking about it for a minute, I think Mercurial’s addremove command is exactly the right behavior for OS X bundles.

Consider. If Keynote adds or removes some graphic asset from inside a file.key bundle, then I would want that asset to be automatically added or removed from version control. As long as version control lets me go back and reconstruct an earlier version of the file.key bundle, including that asset, then I’m fine. In fact, I don’t want the version control system to keep resist Keynote’s actions on files within file.key bundles — just to track them. So addremove is perfect.

I checked the man page and git’s “commit -a” has the same effect, automatically adding new files and automatically removing deleted files. So that’s good news too.

FYI, I use fink and fink was able to install both mercurial and git from source without a hitch. (Fink does not have a current version of bazaar, tho.) I’d rather use a good GUI than the command line, but I’ve never seen a revision control GUI that really earned its keep.

This has been a useful discussion! I know this issue is biting a lot of OS X users, but I’ve never seen anyone really hash out the details. The answer seems to be addremove for hg, and “commit -a” for git.

hg add -I '*'
hg commit


The first line will add all files to Mercurial. (The -I specifies an include pattern.) The second, of course, performs the commit. This has the effect of adding any new files that show up without removing the old ones that might have been deleted in the process of revising your presentations.

Although this is a two-step process, you might find Mercurial a little more friendly if you aren’t a Terminal sort. Git requires building from source while Mercurial has binary packages available for OS X.

Thanks for the info. That’s good to know.

My main problem is really Keynote’s .key files. My presentations can easily contain over 100+ graphic assets (equations rendered as pdfs), and I imagine every one of them will appear as a new file inside the file bundle. So I am worried about having to stay on top of the internals of every bundle.

The “commit -a” options sounds like a good solution for when new files appear inside the bundle. Do you happen to know if git has a similar shorthand for when files disappear ? — that is, a commit command which instructs it to assume that all files deleted from the working tree should be deleted from version control as well?

As long as one is diligent to do commits and status checks, there seems to be no problem with either Git or Mercurial. (I’ve now tried both.)

As it appears, the x.pages/ bundle is fairly predictable with an index.xml.gz file, a Contents subdirectory with a PkgInfo file, and a QuickLook subdirectory with Preview.pdf and Thumbnail.jpg. While Apple doesn’t actually “bundle” their bundles (say, with 0-compression ZIP), they do at least Gzip the supporting files that make up the document.

Both Git and Mercurial (and even CVS and SVN) will point out any files inside the working copy that are not under their control, making it easy enough to add them without digging for them. In addition, Git (I haven’t looked into this with Mercurial) supports a “commit -a” mode, which will both add to version control and commit it at the same time, so if a new file does magically pop up, running “commit -a” will add it and commit it without even having to look for it.

At any rate, it isn’t a problem for either Git or Mercurial, provided that you keep on top of any potential “gotchas”. It’s a good idea to do a git status or hg status before running a commit. It works fine. The only complaint is that there is of course too much granularity. I don’t particularly need to keep revision control on index.xml.gz as much as I do x.pages. There’s no way around that (that I’m aware of) without writing a new OS X-centric version control system.

I am facing the same problem and here is my question: does switching to git or mercurial really solve your problem with bundled directories?

Neither git nor mercurial dumps spurious files and directories within the bundles. But they both still require command-line intervention for adding new files and removing old files from revision control, right? So if Pages adds a new “file” deep within a .pages bundle, then aren’t you still required to go burrowing into the bundle to add or remove the file in git?

Perhaps I’ll work on a TextMate plugin for Git. Had I even thought to check TM support, though, I probably would have chosen Mercurial, even though I usually manage my revision control from the terminal anyway.

@Billy Halsey

Regarding comparing Git and Mercurial.

For me, their differences conceptually and performance-wise are insignificant. If you learn one you can apply your knowledge easily to the other.

Mercurial is fast, but Linus claims Git is faster. That would make sense since Mercurial is written in Python and Git is mostly written in C. But the speed difference is insignificant to me and the size of projects that I work on. Mercurial is fast enough.

There is a Git-SVN tools which lets you translate between Git and Subversion. I’ve read developers needing to commit to Subversion but wanting to use a DVCS really like this tool. So Git converts some developers for this reason.

On the other hand, Mercurial converts Windows developers more easily, because Mercurial works with little hassle on Windows and Git doesn’t.

I don’t like the fact that Git installs 146 scripts and executable binaries in your system. That’s way too many, but I’ve read that they’re addressing this issue.

I know Git will get more attention from the Linux community and so the Mac OS X community (which I work in) will be better served if there’s competition. For example, Mercurial can plug-in to TextMate which I use for my Rails development. A Git plug-in for TextMate doesn’t exist yet.

2008 will be an interesting year to see where DVCSs advance. It’s too early to say which, if any, will win, but I hope they tie.

Thanks, Brian, for filling in the blank on other file bundles. I wasn’t sure about those.

If anyone is interested in a precompiled version, I can tar/bz2 my compiled version of git (for Intel, built with gcc 4.2.2, optimized for Core 2 Duo).

@jojo — What do you like specifically about Mercurial? I chose git primarily because it was originally the work of Linus Torvalds and easy enough to migrate from SVN.

Because of this issue, I’m thinking about setting up Git as my solution. Billy, how do you like Git so far?

@Scott and Nigel — I saw that svk would overcome the problem (after writing this article), but I’ve actually already migrated to Git. As I’ll point out in the article I put together at Twist’s suggestion, Git actually works better for my needs anyway because there is no central repository.

As a side effect it does not put any additional data into the working directory.

Mac installers are available, or it can be installed using the MacPorts port command.