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?