3 ms·

I’ve had to use perforce before and was not a fan. Granted, I didn’t have to use it full time and can’t claim to be an expert, but I hated the notion of locking

I’ve had to use perforce before and was not a fan. Granted, I didn’t have to use it full time and can’t claim to be an expert, but I hated the notion of locking files, change lists, yuck. All of it felt so clunky compared to git.

dijit 6y ago
I’m not sure locking files is as important as all that. You “check out” files, but nothing prevents anyone else “checking them out” (which is perforce parlance for: “make editable”) - conflicts can be resolved. There is locking but it’s seldom used- handy in the gaming industry for code which depends on data.
- robaato 6y ago
  As cecilpl2 commented - it's the typically the binary art assets (occasionally other files) which are unmergeable which need the exclusive lock turned on. And of course you want to avoid branching those too in many cases.
simiones 6y ago
Funny - I used P4 for about 7 years before switching to Git 2 years ago, and Change Lists are what I miss most from P4. For me it is extremely common to work on multiple changes in parallel, on the same branch or different branches, and organizing my changes in different change lists was the best way to handle it. I also find git's default of rewriting your worktree when you switch to a different branch extremely annoying compared to simply having each branch be a different directory in the FS. Fortunately, digging around I recently discovered git worktree and I'm much happier on this front at least. The file locking was always a relatively obscure workflow, so I'm surprised that you even had to see it if you didn't use P4 a lot. I've only seen it in 3 occasions: working with binary files, the error message when I didn't actually have write access, and when someone intentionally locked some files to make sure they don't have any merge conflicts while they finish up a huge commit.
cecilpl2 6y ago
Locking files is critical when you are editing binary data which can't be merged - which in the games industry, is generally how the majority of the dev team works.

dijit 6y ago

I’m not sure locking files is as important as all that. You “check out” files, but nothing prevents anyone else “checking them out” (which is perforce parlance for: “make editable”) - conflicts can be resolved. There is locking but it’s seldom used- handy in the gaming industry for code which depends on data.

robaato 6y ago
As cecilpl2 commented - it's the typically the binary art assets (occasionally other files) which are unmergeable which need the exclusive lock turned on. And of course you want to avoid branching those too in many cases.

simiones 6y ago

Funny - I used P4 for about 7 years before switching to Git 2 years ago, and Change Lists are what I miss most from P4. For me it is extremely common to work on multiple changes in parallel, on the same branch or different branches, and organizing my changes in different change lists was the best way to handle it. I also find git's default of rewriting your worktree when you switch to a different branch extremely annoying compared to simply having each branch be a different directory in the FS. Fortunately, digging around I recently discovered git worktree and I'm much happier on this front at least. The file locking was always a relatively obscure workflow, so I'm surprised that you even had to see it if you didn't use P4 a lot. I've only seen it in 3 occasions: working with binary files, the error message when I didn't actually have write access, and when someone intentionally locked some files to make sure they don't have any merge conflicts while they finish up a huge commit.

cecilpl2 6y ago

Locking files is critical when you are editing binary data which can't be merged - which in the games industry, is generally how the majority of the dev team works.