6 ms·

This would never work. If someone checked out a file, locked it, and then went on vacation, this would block everyone else. Imagine if some breaking bug was in

by dexwiz 5y ago

This would never work. If someone checked out a file, locked it, and then went on vacation, this would block everyone else. Imagine if some breaking bug was in the checked out file, now you have to find some admin to remove the lock. You could put a timer on the lock, but how would this be different from git? Perforce does trunk based development and checkouts involve talking to the server (depot). This allows you to see who else has a file checked out, but doesn't block you from editing. I have used Perforce for multiple years in a thousand+ developer org, and have never actually needed to see who else has a file checked out.

zwieback 5y ago
We still use Perforce as well, for some projects. We also don't use exclusive (locking) checkout and merge problems are resolved the usual way. I do like to see who else has a file checked out because you can usually also tell which workspace it's checked out to, in our environment that's quite helpful since I can tell which PC it's on.
HALtheWise 5y ago
Presumably, you would have a mechanism for "stealing" a lock from someone who's on vacation. Their branch would be left in an unmergable state until they re-apply their updates on top of yours.
vb6sp6 5y ago
mattchamb 5y ago
Microsoft TFS has exclusive checkout and this is exactly what happens. Someone locks a file and forgets about it.
drakonka 5y ago
When I've worked with Perforce it was quite common to double check who has the file checked out and lock when necessary, especially for content creators. And to sometimes use exclusive checkout on certain file types or directories (though this was thankfully more rare). Some of the versioned files being modified while working on game data are difficult to manually resolve conflicts in. At best they're a bunch of XML that you can kind of decipher but which contain various UUIDs to different assets and schematics connections which are not intuitive to resolve by hand. At worst they aren't even parse-able by a normal human. Then you have things like versioned animation sandboxes which have to be locked for any changes and submitted from a CI machine, not allowing any content creator to touch them lest they don't have the right source locally to reimport from. Files were even locked while running through a presub process to ensure no conflicts were introduced between presubmit initialization and commit. Users could check them out and work on them, but not submit until the in-flight presub touching those files was done (at which point you just hope that the conflict won't be too painful to resolve). Having locked files was usually considered a hassle though, and more of a necessity of an imperfect workflow rather than a feature. Having the _option_ to lock was often very useful and practical, but actually running into a locked file when you just want to change an asset configuration or something could be annoying.

by dexwiz 5y ago

zwieback 5y ago

We still use Perforce as well, for some projects. We also don't use exclusive (locking) checkout and merge problems are resolved the usual way. I do like to see who else has a file checked out because you can usually also tell which workspace it's checked out to, in our environment that's quite helpful since I can tell which PC it's on.

HALtheWise 5y ago

Presumably, you would have a mechanism for "stealing" a lock from someone who's on vacation. Their branch would be left in an unmergable state until they re-apply their updates on top of yours.

vb6sp6 5y ago

mattchamb 5y ago

Microsoft TFS has exclusive checkout and this is exactly what happens. Someone locks a file and forgets about it.

drakonka 5y ago

When I've worked with Perforce it was quite common to double check who has the file checked out and lock when necessary, especially for content creators. And to sometimes use exclusive checkout on certain file types or directories (though this was thankfully more rare). Some of the versioned files being modified while working on game data are difficult to manually resolve conflicts in. At best they're a bunch of XML that you can kind of decipher but which contain various UUIDs to different assets and schematics connections which are not intuitive to resolve by hand. At worst they aren't even parse-able by a normal human. Then you have things like versioned animation sandboxes which have to be locked for any changes and submitted from a CI machine, not allowing any content creator to touch them lest they don't have the right source locally to reimport from. Files were even locked while running through a presub process to ensure no conflicts were introduced between presubmit initialization and commit. Users could check them out and work on them, but not submit until the in-flight presub touching those files was done (at which point you just hope that the conflict won't be too painful to resolve). Having locked files was usually considered a hassle though, and more of a necessity of an imperfect workflow rather than a feature. Having the _option_ to lock was often very useful and practical, but actually running into a locked file when you just want to change an asset configuration or something could be annoying.