3

Specifically the situation I'm thinking of is you have a large asset like a .psd that is 200 MB. An artist goes and changes a few pixels and checks it in. Assuming deltas are not kept thats 200 MBs that anyone that updates to his clone/branch will have a history off. Given a full development cycle that is a LOT of information to pull for each client.

What I would like is the ability to mark files like these as "keep history on server", much like traditional centralized VCSs like SVN or Perforce. You may lose the benefits of a DVCS for these files but I am willing to accept that as long as I can use one VCS (as opposed to 1 for assets and 1 for code).

Any suggestions on how to do this (if even possible) would be greatly appreciated.

SilentDirge
  • 827
  • 9
  • 17

2 Answers2

7

For Mercurial, you can use bfiles extension (or one of the others that are listed on that page). Then only file metadata is stored inside the repo, and the content of big files is kept on a central server. I haven't used any of those extensions, though, so I can't tell which one would be the best choice.

Cat Plus Plus
  • 125,936
  • 27
  • 200
  • 224
3

Even though this is not a DVCS, you may want to look at Dropbox. You mostly work with the recent version of each tile but it keeps versioning information for each file so you can get back to the previos version if necessary. They also use binary deltas which may reduce upload/download times.

One big advantage of Dropbox is a very natural user interface which virtually every computer user is comfortable with. I have tried in the past to get designers and other non-technical people to use engineering version control systems and it wasn't always easy for them.

Sasha O
  • 3,710
  • 2
  • 35
  • 45