[dagmx]

I think this is a very p4 centric view of the world.

Locking helps with preventing collisions, but honestly the issue is still always communication. Why are people even touching files they shouldn't be touching?

Meanwhile perforce is a pain for code heavy projects and requiring a central perforce server. Git works great there.

The issue is neither is a silver bullet for the others workflow and needs, and they both suck horribly for mixed code and binary asset workflows.

That's not even considering cost.

Meanwhile film studios generally prefer keeping the considerations separate and using symlinks or URI to their data store and that works really well. But that doesn't work great for remote workflows.

So again, I think you're applying a very p4, game centric view to this. There are lots of different use cases and team structures that none of these version control systems are able to address in their entirety.

[maccard]

> 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.

[dagmx]

Meanwhile film studios go on with 300+ people without hitting the issue of people hitting the same asset files without needing locking.

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.

[vvanders]

If by P4 centric you also mean SVN as well then sure.

I will say however that if you think locking is optional then you already don't understand these workflows and why they're so critical. Art/design/animation doesn't care that "they should not have been touching the file" they just care that they have to throw away two days of work because someone made multiple edits to the same package file. I've literally seen multiple teams almost come to blows when this happens.

You can separate code from art/assets. That comes at an integration and iteration cost, it'll drive your designers mad.

There are workflows out there where code is not the first class citizen, in those cases I've seen git shoehorned in and untold pain follows.

[dagmx]

I've worked as a pipeline supervisor at one of the biggest VFX studios. I very much understand these workflows. I've worked as an artist and a tech artist in perforce and SVN workflows too. I've had to support the workflows of a 1000+ workforce across multiple locations.

I don't think attributing my disagreement with you to not understanding workflows is a fair characterization.

I still think locking , while useful, is only mandatory for work cultures with poor communication. Otherwise, many companies get by with very large workforces who don't hit these issues without having locking.

Separation of code and art assets also don't need to be painful. It's very doable but does require some amount of architectural consideration.

And I very much acknowledge there are projects where code isn't the majority makeup, which is why I say that none of the VCS systems cover mixed projects well or cover all the needs of the others well.

[vvanders]

I think we'll just have to agree to disagree.

It sounds like we just come from different development cultures. Your solution to lack of locking sounds like a top-down hierarchy that wouldn't be flexible enough to support the teams I've worked with.

Having seen both approaches(and how they break down) I'll take a centralized locking solution over communication mistakes that lead to days of work being lost.

[dagmx]

That's fair to agree to disagree but I also again think it's unfair to characterize my pipelines as not flexible enough.

For context I developed the publishing pipelines for the majority of departments in the studio. I have several hundreds of assets being published through my pipelines on a daily basis, if not more, from a variety of departments.

We only hit collisions on a very rare basis, and which were often resolved in an hour or two in the worst case.

We've scaled this from very small teams to large ones, from very scrappy realtime productions to feature length offline rendered films.

I don't doubt that locking helps. I just argue that maybe it's not as critical as people make it out to seem.

[vvanders]

What happens if you're not around to drive the process? What about if you don't have the organizational backing to drive the process? What if a team goes AWOL or isn't bought in to your process? I've seen variants of all those happen in production in one form or another.

At the end of the day humans make mistakes, especially when involving communication. I'd rather have a physical system that prevents breaks instead of requiring cross-team/cross-discipline coordination.

Maybe gamedev is much more coupled than film(we regularly had design, animation, art and code touching the same common core packages). Look at Unreal or any other gamedev pipeline and you'll see a bias for locking source control solutions.

[dagmx]

It's very rare that someone needs to be around to oversee the process. Tooling guides the vast majority of users in to a workflow that works while still being flexible should they need it.

Lack of organizational backup, do you mean cultural from the studio or infrastructure? Both are a problem no matter what solution you pick.

If a team goes AWOL, that's on them. The tooling usually allows for some amount of arbitrary workflow but they can't go completely off the rails. But that's true of p4 too. So I think that scenario would have to be more specific.

And yes people make mistakes, and you need tooling to guide them. Locking is a tool, but it's not the only tool. I feel very much that many workflows use it to hide deeper issues. That's not to say it's not valid, it is, but it's not a panacea either.

Unreal heavily favors perforce and SVN because that's what it was designed around. There's no absolute reason it could not work with other versioning systems and their paradigms if it came to being necessary.

Unity on the other hand is quite happy to work with any version control system, and works quite well with git or perforce.

You again seem to be trying to approach this from the angle of only the system you're familiar with working. But maybe try stepping outside the box and seeing if your workflow isn't a byproduct of your tools.

After all, you were asking git users to look at perforce as the solution. I don't think it's fair to then go ahead and assume that p4 is the only workable solution.

[adrianmonk]

> Why are people even touching files they shouldn't be touching?

I don't think it's accurate to say they shouldn't be touching the files.

It's possible to make two unrelated changes in the same binary file just as it is possible to make two unrelated changes in a source file (or other merge-friendly text file).

Just as there may be nothing wrong if one person changes the function foo() in a file and someone else changes the function bar() in that same file, there may be nothing wrong if one person opens a CAD file and makes a change to a drawing in one part and another person makes a change to a different part of the same drawing.

In that case, they could coordinate by communicating (even though their tasks are unrelated) but then they're just doing the same thing as locking the files but manually and informally (and probably inconsistently) without the benefits of automation.

Of course there are times when locking catches failures to communicate, but that doesn't mean that that's what locking is for.

[dagmx]

Sure, but I would argue it's a poor system that is setup to require serial editing to a non diffable file.

Again, I'm not saying locking is an invalid solution. It is. But to me, it's often (but not always), a crutch for a deeper issue.

That binary file should be set up to be modular if it is intended to have areas that multiple users can touch without directly affecting each other.