4 ms·

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

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.
caf 10y ago
I'm just not convinced that they should be solved by VCSs - I tend to think that the general issue of conflicting changes calls for a social/process solution, not a technical one. Does the set of "lock/unlock/revoke" operations really add much over sending an email to a list or designated object owner saying "I need to update the Visio diagram"?

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.

caf 10y ago

I'm just not convinced that they should be solved by VCSs - I tend to think that the general issue of conflicting changes calls for a social/process solution, not a technical one. Does the set of "lock/unlock/revoke" operations really add much over sending an email to a list or designated object owner saying "I need to update the Visio diagram"?