5 ms·

Version control is not enough for binary files. Binary files need access control since changes can not be merged. Older centralized version control often provid

Version control is not enough for binary files. Binary files need access control since changes can not be merged. Older centralized version control often provides access control as well. Distributed version control can't do this by it's very nature

jordigh 12y ago
Like they say, there's an extension for that: http://mercurial.selenic.com/wiki/LockExtension http://mercurial.selenic.com/wiki/LockExtension
- greggman 12y ago
  Unfortunately by definition that's not a solution. Because hg is distributed checking out the file locally does nothing unless the fact that it's locked is propagated to everyone else's copy of the repo immediately and that doesn't happen.
  - jordigh 12y ago
    By definition? Did you even see what this does?
to3m 12y ago
I'm not sure why this ever got downvoted, because it's a key point. Unless you've got some kind of exclusive check out/check in type facility, working with unmergeable binary files is going to prove a pain. It's no fun having people find out once they come to commit/check in/merge/etc. that they've got the unenviable choice of losing their work, or losing somebody else's... or losing both. (The disk space problem is far less of an issue - disk space is cheap, and networks are pretty fast, so up to some medium repository size of (I suppose) hundreds of GB you can actually just let it build up. This doesn't scale completely, but for many projects, possibly even most of them, if everybody has a copy of absolutely everything, it's no problem.) For whatever reason DVCS users often have a bit of a blind spot in this regard. Because DVCSes are good, the thinking often seems to run, if DVCSes handle something poorly, that must be something that revision control simply isn't to be used for. ("You must be using it wrong. Try storing everything on a shared drive and take daily backups and coordinate access using physical tokens.") Which is wrong, because revision control is for everybody, not just the programmers. People who work on unmergeable binary files need it too. But fortunately, even if git/etc. and their users doesn't care about you, you're not completely stuck. if you have lots of binary files your needs are fairly well served by Perforce, and you can probably get on OK with SVN and its locking facility.
Jare 12y ago
PlasticSCM [1] offers a mixed approach to handle both distributed and centralized patterns for both large files and branch-happy repositories. It's worth checking out. Some mid-size game studios are using it successfully, and I plan on a serious testdrive as soon as I can catch a breath. [1]: http://www.plasticscm.com/home.html http://www.plasticscm.com/home.html
danielbarla 12y ago
This is an excellent point; I guess you can't drop the "connectivity to central server" requirement and still implement global locking. Having said that, some DVCSes do support a form of locking - similarly to changes, tags, etc, locks can be created and pushed / pulled. An example would be Veracity's implementation: http://veracity-scm.com/qa/questions/1105/how-do-file-locks-work http://veracity-scm.com/qa/questions/1105/how-do-file-locks-... Obviously this is not quite as foolproof as with a centralised version control system, but using strict workflows (i.e. always pushing locks immediately and pulling before you work on binary files) could create a workable compromise. I suppose you could create some plugins for your favourite DVCS to emulate this behaviour, and to enforce the workflow.

jordigh 12y ago

Like they say, there's an extension for that: http://mercurial.selenic.com/wiki/LockExtension http://mercurial.selenic.com/wiki/LockExtension

greggman 12y ago
Unfortunately by definition that's not a solution. Because hg is distributed checking out the file locally does nothing unless the fact that it's locked is propagated to everyone else's copy of the repo immediately and that doesn't happen.
- jordigh 12y ago
  By definition? Did you even see what this does?

to3m 12y ago

I'm not sure why this ever got downvoted, because it's a key point. Unless you've got some kind of exclusive check out/check in type facility, working with unmergeable binary files is going to prove a pain. It's no fun having people find out once they come to commit/check in/merge/etc. that they've got the unenviable choice of losing their work, or losing somebody else's... or losing both. (The disk space problem is far less of an issue - disk space is cheap, and networks are pretty fast, so up to some medium repository size of (I suppose) hundreds of GB you can actually just let it build up. This doesn't scale completely, but for many projects, possibly even most of them, if everybody has a copy of absolutely everything, it's no problem.) For whatever reason DVCS users often have a bit of a blind spot in this regard. Because DVCSes are good, the thinking often seems to run, if DVCSes handle something poorly, that must be something that revision control simply isn't to be used for. ("You must be using it wrong. Try storing everything on a shared drive and take daily backups and coordinate access using physical tokens.") Which is wrong, because revision control is for everybody, not just the programmers. People who work on unmergeable binary files need it too. But fortunately, even if git/etc. and their users doesn't care about you, you're not completely stuck. if you have lots of binary files your needs are fairly well served by Perforce, and you can probably get on OK with SVN and its locking facility.

Jare 12y ago

PlasticSCM [1] offers a mixed approach to handle both distributed and centralized patterns for both large files and branch-happy repositories. It's worth checking out. Some mid-size game studios are using it successfully, and I plan on a serious testdrive as soon as I can catch a breath. [1]: http://www.plasticscm.com/home.html http://www.plasticscm.com/home.html

danielbarla 12y ago

This is an excellent point; I guess you can't drop the "connectivity to central server" requirement and still implement global locking. Having said that, some DVCSes do support a form of locking - similarly to changes, tags, etc, locks can be created and pushed / pulled. An example would be Veracity's implementation: http://veracity-scm.com/qa/questions/1105/how-do-file-locks-work http://veracity-scm.com/qa/questions/1105/how-do-file-locks-... Obviously this is not quite as foolproof as with a centralised version control system, but using strict workflows (i.e. always pushing locks immediately and pulling before you work on binary files) could create a workable compromise. I suppose you could create some plugins for your favourite DVCS to emulate this behaviour, and to enforce the workflow.