mercurial - Git style backup of binary files

Question

I'm in process of integrating GIT version control system into 3ds max to control .max file versioning.

I tested git with max files for several weeks and have found that it suites my needs, but, anyway, git is little bit overcomplicated for this kind of tasks. What I'm looking for is the program that works just like (well, almost) git, but:

1. is naturally born windows program - git failed several times on my network shared folders and destroyed my binary max files. This is the main problem, and I don't know how to solve it.
2. doesn't (doesn't even try to) process file content. I think that speeds up the workflow.
3. has interface close to TortoiseGIT.

What this software has to have is:

1. commit and log commands
2. branching support
3. be distributed and not server oriented like Perforce.

I tested Mercurial, but it is really slow on large binary files. If someone knows how to speed it up (by disabling content management, I suppose) and have TortoiseHg fully functional, any information would be greatly appreciated.

Thank you!

Answer 1

Binary files have sort of an ambivalent relationship with VCS because:

• they do not merge (so the all "branching support" is not that interesting)
• they do not diff very well (meaning the storage of their history is not very compact)
• they usually can be generated
• or they can be fetched from other kind of repositories

Binary files are part of Git limits as they tend to slow down the all workflow, and do not scale in size (the repo quickly becomes too large to manage/backup efficiently).

So the question is: could you store those files is some other repo than a VCS?
A Maven repo perhaps (managed by a repo manager like Nexus, not exactly distributed, but made to reference precise version of any kind of set of files).

---

Jakub Nar?bski (actual Git contributor) rightly points to a Git fork project able to manage more efficiently big files.

[git-bigfiles (ok, the project logo is awesome ;) )

The question remains: is a VCS the right tool for managing such large objects?
Because in my experience, the question of "cleaning up the history" will be asked one day or another, because of a ever increasing amount of disk space used.
And VCS are fundamentally not made for "clean-up" their history.
Git itself cannot do it without changing its SHA1 key, making any future publication to other public repo problematic.