|
|
|
|
|
|
by maccard
2286 days ago
|
|
|
> but honestly the issue is still always communication. Why are people even touching files they shouldn't be touching? Because there's 300+ people working on a project, and it's not feasible to know what every other person is working on or planning on working on. The file lock (code can be merged too, just like git, so this is only really for binary assets) is a crude communication tool saying "hey I'm using this file". > Meanwhile perforce is a pain for code heavy projects and requiring a central perforce server. Git works great there. I think you're applying a git biased view here. I don't think perforce is unsuitable for code heavy projects at all (see workspace views as a prime example), and for the majority of people, having a central server isn't an issue. Most people treat github/gitlab as a centralised server anyway. I've _never_ in a decade of programming heard someone suggest adding an extra remote to git so I can share your changes, it's always been "push it as a separate branch and I'll merge it". If you have a missing internet connection, you're likely not able to share code _anyway_, and with p4 you can always reconcile offline work when you're back online. |
|
|
I think locking is a fine utility to have but I think a lot of workflows use it to workaround poor communication.
And I think you're constraining your views of git to just your workflow.
I've worked in a lot of scenarios where you need multiple remotes such as having an internal repo and an external one.
And similarly there are lots of scenarios where having a decentralized copy of the report is very useful for being able to work in offline scenarios and compare multiple branches. Things like when commuting on a plane or being in low connection areas.
I don't see how my view is git centric. I'm saying each VCS has very useful areas and equally big rough spots. The problem is that each VCS group believes there's is the only right system.