4 ms·

There's one further point the article missed, which is: locking of binary assets. For any file which cannot be merged, you need to have a "lock/checkout, edit,

There's one further point the article missed, which is: locking of binary assets. For any file which cannot be merged, you need to have a "lock/checkout, edit, commit" workflow. There's no point allowing two people to have a PNG file in their checkout, edit it, and commit it, only for one to get the message "sorry, someone else edited it, your edits are now based on an out-of-date version, deal with it". You need to enforce the "lock, edit, commit" workflow on all files which cannot be merged. Essentially, binary files cannot be merged, and therefore all binary files require this workflow. I'm sure there are some exceptions, I think Microsoft offers a merge tool for Word files. But I've never seen it hooked up to a VCS. But I suppose in principle it, or a similar merge algorithm for a particular file format, could be. But even then, there'll still be all the other binary files, for which no such merge algorithm is configured. All project have some binary files e.g. PNGs. So all projects are affected by this, and require this workflow on those files. Yet a DVCS cannot offer it as there is no central place to maintain the lock. Subversion offers this workflow however it isn't enabled by default. A VCS needs to offer this functionality as every project needs it, and it should be enabled by default for all files the VCS doesn't know how to merge.

pjc50 10y ago
Plenty of people get by without it. It's not all that popular because it requires discipline to get people to lock the minimum they need for the minimum time, and of course occasional administrator intervention when someone locks a file and goes on holiday / leaves the company.
caf 10y ago
It's not really so different for mergeable files - just because two independent changes to a file can be automatically merged doesn't mean that the merge result is sensible. You still need a human in the loop to make sure two simultaneous changes didn't conflict semantically, even if they were able to be munged to be compatible syntactically. Does this mean we need locking for everything? No, of course not: people get by, by using out-of-band methods for co-ordinating potentially conflicting work. The same tends to work for binary assets, too.
- adrianmsmith 10y ago
  It's true that a "successful" merge of text source can still result in semantic conflicts, I definitely agree and have experienced it. But the fact text merging works most of the time is justification to use it. But merging binary assets works 0% of the time, so it's a much more severe problem. Further to it happening more often, the consequences when it does happen are worse. You can't even do a diff of binary files. If text source changes lead to problems you can look at the diff and gain an understanding of what was changed. (e.g. A renamed a method, but B checked in new code using the old method name). If you spend time altering a Visio file, only to receive the error message that it can't be merged, you literally have no other option than to open the original, theirs, yours, and try and look at it and hope you see all changes. We should aspire to more than just "get by". The above problems can be solved by VCSs, just not DVCSs.
  - toyg 10y ago
    Git in its current form is usually not a pure DVCS though; everyone has a "canonical" repo somewhere, be it a buildbot or github/gitlab. If Git supported synchronised "lock flags", people would just need to make sure they pull from their canonical repo before trying to edit binary files. You should be able to mark specific files or directories as "lockable". As it is, you could implement this sort of workflow manually or via an extension, pushing a special file before one starts working on binary assets ("git binedit" ?). It would pollute the commit log a bit, which is why it would be better if it were a native feature, but imho it could be done.
    - WorldMaker 10y ago
      Rather than a special file you could use special branches and a new primitive git object for those branches. Git garbage collection would eventually deal with the pollution of that. Using commits (with no file contents) as your locks (rather than creating a new git primitive object), you'd have an easily automatable workflow along the lines of: # Clear current locks git push origin --delete binedit/WorldMaker git branch -D binedit/WorldMaker git gc # Optionally force a garbage collection # Create new lock git checkout master -b binedit/WorldMaker git commit --allow-empty -m "binedit: file/to/edit.psd" git push --set-upstream origin binedit/WorldMaker git checkout master # Avoid adding actual commits to the binedit branch Searching for binedit locks would be git fetch all remote binedit/* branches and review their commit messages. Not the fastest system to query in the world, but you could cache it well, presumably. You can also fetch such branches from multiple remotes, leaving it somewhat distributed a tool, too.

pjc50 10y ago

Plenty of people get by without it. It's not all that popular because it requires discipline to get people to lock the minimum they need for the minimum time, and of course occasional administrator intervention when someone locks a file and goes on holiday / leaves the company.

caf 10y ago

It's not really so different for mergeable files - just because two independent changes to a file can be automatically merged doesn't mean that the merge result is sensible. You still need a human in the loop to make sure two simultaneous changes didn't conflict semantically, even if they were able to be munged to be compatible syntactically. Does this mean we need locking for everything? No, of course not: people get by, by using out-of-band methods for co-ordinating potentially conflicting work. The same tends to work for binary assets, too.

adrianmsmith 10y ago
It's true that a "successful" merge of text source can still result in semantic conflicts, I definitely agree and have experienced it. But the fact text merging works most of the time is justification to use it. But merging binary assets works 0% of the time, so it's a much more severe problem. Further to it happening more often, the consequences when it does happen are worse. You can't even do a diff of binary files. If text source changes lead to problems you can look at the diff and gain an understanding of what was changed. (e.g. A renamed a method, but B checked in new code using the old method name). If you spend time altering a Visio file, only to receive the error message that it can't be merged, you literally have no other option than to open the original, theirs, yours, and try and look at it and hope you see all changes. We should aspire to more than just "get by". The above problems can be solved by VCSs, just not DVCSs.
- toyg 10y ago
  Git in its current form is usually not a pure DVCS though; everyone has a "canonical" repo somewhere, be it a buildbot or github/gitlab. If Git supported synchronised "lock flags", people would just need to make sure they pull from their canonical repo before trying to edit binary files. You should be able to mark specific files or directories as "lockable". As it is, you could implement this sort of workflow manually or via an extension, pushing a special file before one starts working on binary assets ("git binedit" ?). It would pollute the commit log a bit, which is why it would be better if it were a native feature, but imho it could be done.
  - WorldMaker 10y ago
    Rather than a special file you could use special branches and a new primitive git object for those branches. Git garbage collection would eventually deal with the pollution of that. Using commits (with no file contents) as your locks (rather than creating a new git primitive object), you'd have an easily automatable workflow along the lines of: # Clear current locks git push origin --delete binedit/WorldMaker git branch -D binedit/WorldMaker git gc # Optionally force a garbage collection # Create new lock git checkout master -b binedit/WorldMaker git commit --allow-empty -m "binedit: file/to/edit.psd" git push --set-upstream origin binedit/WorldMaker git checkout master # Avoid adding actual commits to the binedit branch Searching for binedit locks would be git fetch all remote binedit/* branches and review their commit messages. Not the fastest system to query in the world, but you could cache it well, presumably. You can also fetch such branches from multiple remotes, leaving it somewhat distributed a tool, too.