One of the many points of git's design is that most of the steps you need to do in P4 are not necessary at all. You do not "lock assets", you do not "release them", there is no "merging into streams" equivalent.
The entire workflow with git avoids huge amounts of the cognitive load of using P4, which in turn means that integration with IDEs becomes much less important.
I worked with P4 around the time I first started learn git (coming to both from SVN). P4 struck me as "what a for-profit corporation would imagine a VCS should be like, if they'd never seen git". So glad to be far, far from that particular tool now.
Solving merge conflicts on text-based files is infinitely easier than binary-based. It's not a useful comparison.
What does that have to with your VCS being integrated with your IDE? Isn't resolving merge conflicts in binary files going to entirely a function of the IDE and not the VCS ? What am I missing?
Merge conflicts on binary files are typically unresolvable in practice because the editing tools don't normally have the ability to compare files. This leads to one of the two divergent sets of changes getting lost. That's why great VCSes allow file locking: locks are a communication tool between team members to avoid losing work.
a great VCS wouldn't require locking or pre-communication; it would simply refuse to even try to merge assets it couldn't deal with, and leave the result of a merge in a state where the user can reasonably address it (in this case, presumably just "yes, use mine" or "no, use the one already in the repo" and perhaps "use mine but rename it").
I don't get it. Now your options are to lose your work, or for somebody else to lose theirs, or, maybe an un-fun manual merge process - and this after you've both done the work! With a per-file lock, on the other hand, you can't start work until you've got the lock, which prevents others from starting work on that file in the meantime.
(It's usually possible to bypass the locking mechanism, but this is not a habit people get into, because the end result is the situation you describe, and nobody wants to end up there.)
We seem to be in some kind of local minimum here, but perhaps LLMs might help us escape it by facilitating the creation of more merge tools.
> You do not "lock assets",
Uhhhhhh. Locking binary assets is ABSOLUTELY NECESSARY in Git. Except Git can't actually do that. So what locking binary assets Git looks like in practice is an unenforced message in Slack saying "hey I'm changing this file please no one else touch it".
Git's design provides zero value and zero affordances for solving the very very real problem of unmergable binary assets.
> there is no "merging into streams" equivalent.
Weird take. Streams is Perforce's mediocre take on Git branches. P4 stream merge is close enough to Git branch merge that I would say they're in the same family.
> P4 struck me as "what a for-profit corporation would imagine a VCS should be like, if they'd never seen git".
And yet Git has almost zero mind share in gamedev because it doesn't solve the problem.
P4 is somewhat mediocre. And it's made zero improvement in ~8 years since getting bought up by PE.
But I can also teach a game designer or artist who has never heard of source control how to correctly and safely use P4 in about 15 minutes. Meanwhile you can tell Git is badly designed because there are 10,000+ tutorials explaining how easy it is! Spoiler: things that are actually easy do not need 10,000 tutorials telling you that it is easy.
> Git's design provides zero value and zero affordances for solving the very very real problem of unmergable binary assets.
OK, I think this is well-established by up-thread comments, and I don't disagree with it at all (though note that its not just binary assets, it's anything that isn't line oriented, which includes for example XML).
I didn't realize that LinearIO's comment was really that specific; it appeared to be describing general properties of P4 unrelated to the binary issue.
The 10k tutorials on git might indicate issues with its design, or it might indicate its massive popularity. Hard to say.
I just remember that learning to use P4 required learning a ton of concepts for what P4 thinks your workflow ought to be; learning git has largely just required a simple 1:1 mapping between git commands and the things I do with VCS 98% of the time.
> The 10k tutorials on git might indicate issues with its design, or it might indicate its massive popularity. Hard to say.
It's "hard to say" if you want to ignore the fact that it requires 10k tutorials. Meanwhile, there are 500+ person companies with non technical users using P4 with literally 0 onboarding other than "by the way, undo is broken don't use it".
> I just remember that learning to use P4 required learning a ton of concepts for what P4 thinks your workflow ought to be; learning git has largely just required a simple 1:1 mapping between git commands and the things I do with VCS 98% of the time.
Using P4 is: Download P4V, install plugin for $EDITOR, and double click on a changelist to submit.
the fact that 10k tutorials exist says way more about the human urge to write, document, and share information than git itself. the 10k number is also a made up statistic. It might be 2k, it might be 20k. i use git daily and often fairly intensively, and i've read perhaps 5-10 tutorials, so the idea that "git requires 10k tutorials" just doesn't make any sense.
if anything, the fact that something with good search-fu might find a tutorial more specifically catering to their background and needs seems like a huge plus for git.
> Using P4 is: Download P4V, install plugin for $EDITOR, and double click on a changelist to submit.
"a changelist" ... "what the hell is that? I've been editing my files, I don't have "a changelist"."
and anyway, joining a company that's already using P4 is never, ever going to be that simple (even if it was actually that simple as the first user, which I question)
Honestly, when our backend team merged into one that was using Perforce for the backend learning how to use Perforce wasn't realistically even a blip on the radar of what to get used to. I was against it at the time for what we were doing but with the benefit of hindsight I can say that I prefer something like Perforce if someone can manage it for me, or it's a set-and-forget type situation; I don't personally have a lot of use for the distributed part of DVCS.
Currently I use Fossil for most projects, but it's not a compelling choice (just like git) for when you have binary stuff. You've got `fossil uv` for unversioned files, but I think I would rather just sidestep the entire problem with a better versioning model than what we've settled on for text files.
> Honestly, when our backend team merged into one that was using Perforce for the backend learning how to use Perforce wasn't realistically even a blip on the radar of what to get used to.
I think a lot of what people are assuming here is that because git has such a steep learning curve, P4 does too. You can literally ignore all of the concepts that P4 has and still muddle your way into getting things updated.
All I can say is that wasn't my experience with P4 in 2015.
> But I can also teach a game designer or artist who has never heard of source control how to correctly and safely use P4 in about 15 minutes. Meanwhile you can tell Git is badly designed because there are 10,000+ tutorials explaining how easy it is! Spoiler: things that are actually easy do not need 10,000 tutorials telling you that it is easy.
100% and LOL. Sometimes I wonder where we'd be if Mercurial (hg) had won that contest.
Hoverjets, probably.
If you're not sick of hearing about it, jj is git-compatible, and borrows heavily from hg's UI and terminology. It's CLI is concistent, logical, and easier to pick up than git.