Derrick Stolee <stolee@xxxxxxxxx> writes: > On 9/25/2019 9:36 AM, Pierre Tardy wrote: [...] >> And why restrict on DVCS? >> Isn't it admitted that the distributed version control is nowadays >> much better in term of software productivity? >> Is there some use cases that "traditional" centralized VCS are better >> on, and on which we gave up as a goal? > > My intention was "let's be the best at what Git is good at: distributed > version control." There are some legitimate reasons why someone would > pick something like Perforce instead. > > Some things, like *file locking*, are just easier in centralized systems. > I know that Git-LFS created a locking mechanism that pushes even further > toward a centralized system. However, it relies on users following a > very careful pattern (lock, pull, edit, push, merge, unlock) to avoid > conflicts. Further, that only works if you are on a common trunk. > Release branches or forks do not have this concept. Well, there is (or perhaps was, as the latest release is from 2013) DVCS named Veracity that tried to be better than other DVCS in corporate environment. It did include file-locking: http://veracity-scm.com/ https://ericsink.com/vcbe/html/veracity_locks.html But perhaps there would be a better solution to handling file types that do not support conflict resolution at all than file-level locks: see the “Git for games: current problems and solutions” presentation by John Austin at Git Merge 2019: https://www.youtube.com/watch?v=K3zOhU3NdWA&list=PL0lo9MOBetEFqBue4vNcTEnkBjgIQU1Q3&index=8&t=0s Though the tool mentioned here had not seen any significant development since Feb 1, 2019 (well, at least in the public repo at GitHub). >From Git Rev News: Edition 48 (February 27th, 2019) https://git.github.io/rev_news/2019/02/27/edition-48/ GR> John Austin, game studio technical lead from A Stranger Gravity and GR> Funomena in “Git for games: current problems and solutions” talked GR> about major problem with using Git in game development workflows, GR> namely many and large binary files, for which file conflicts are GR> lost work (minor change, like adding voiceover or changing equalizer GR> settings results in large changes to files). File locking is one GR> possibility, but it doesn’t play nicely with Git – it is inherently GR> centralized. He introduces a new tool, [Git Global Graph][1] (a work in GR> progress), which can be used to check at commit time if it wouldn’t GR> create a divergent version of a file. The idea is that there should GR> be only a single path through commit graph with changes to binary GR> files. [1]: https://github.com/Kleptine/gitglobalgraph Best, -- Jakub Narębski
