Perforce has the same problem. UE4's Perforce integration solves the problem by preventing you from checking out any file that has a newer version in a different branch (through the editor interface, anyhow, you can still check out such files in P4V or via the command-line).

Problem:
Once a file is checked in, the lock is released. This becomes problematic with the branch heavy style of Plastic and files that do not merge cleanly.

Problem Example:
1) Joe creates a new branch, modifies a file, commits his change on his branch (releasing the lock on the file), continues working on his branch but does not merge his work into main yet.

2) Beth also creates a new branch to begin work. She modifies the same file Joe did (because it's unlocked now but TECHNICALLY out of date), checks in her work, and merges her branch back into main

3) Joe finishes his work and goes to merge his branch back into main. He now gets a merge conflict because both him and Beth worked on the same file.

Potential Solution:
If a file has been modified but NOT check back into the projects main branch, it's flagged. When someone goes to checkout a flagged file, they'd see a warning that the flagged file has been modified on another branch by X person but not YET checked back into main. They could then choose to check out the file anyway or cancel the request to check out the file. This would at least give users a warning that a file they are going to modify has been modified somewhere else and they could encounter a merge conflict. This becomes a real problem when working with files like Unity Scenes which do not merge cleanly.

I've discovered another sour aspect of this dysfunction: Merging.

Scenario:
Artist changes "Foo" on "art" branch, checks it in alongside "Bar"
Artist gets feedback and starts modifying "Foo" again, checking it out
Developer needs "Bar" in order to do their work, so they try to merge from "art" to "dev"
But it doesn't work - the merge contains a revision to "Foo", and "Foo" is currently checked out, so the merge fails.

The merge shouldn't fail, because it's not actually creating a new revision of "Foo" - it's carrying over an older version. Plastic has no reason to think that "Foo" will be modified as a part of the merge, because it's "changed on source only, no conflict".

My team runs into this every other day. It happens increasingly often as we move from "building new features" to "revising existing features" - a situation where, ironically, exclusive checkout is even more important. In order for developers to not be completely blocked by checkouts that have no logical reason for blocking their needed merge, we need to either check-in prematurely, or shelve changes (in the case of Gluon users, this means copy to desktop, then unco, then move back from desktop after coworker has finished merging).

It's a major waste of time, and we're starting to question if maybe it's a bigger waste of time than running into conflicts, or doing exclusive checkout manually through something like a Google Doc of "who has what".

Please please please fix this, it's SUCH a pain. We've run into this problem a lot with people making changes to Unity scenes on their branch, checking in their work on their branch, then someone else making a change to the same file (once the lock as been released because they checked in their work on their branch but not yet merged back into main). Then some unlucky soul gets hit with the conflict and the debate around who wants to discard and redo their work begins. When someone goes to check out a file, it should do a check to see if the file has changed somewhere else in the project at at the very least WARN them that if they modify said file there maybe a conflict.

I'm in strong support of this. This highlights a serious flaw that objectively cripples the lock system. I hope that the misinterpretations in the comments don't hurt the chances of this becoming a feature. I'll try to clarify even more. This is even more important for UE4 where Blueprints are even less mergeable than Unity assets.

The way it currently works:
1. Alice checks out Foo.uasset on branch main/A
2. Bob cannot check out Foo.uasset because it is locked
3. Alice checks in Foo.uasset on branch main/A
4. Bob can now check out Foo.uasset on branch main/B, which he does
5. Bob checks in Foo.uasset on main/B
6. Admin tries to merge branches A and B into main, but there is a merge conflict for the unmergeable Foo.uasset - why did we even bother with locks in the first place?

How it SHOULD work:
1. Alice checks out Foo.uasset on main/A
2. Alice checks in Foo.uasset on main/B
3. Bob tries to check out Foo.uasset, but it fails because it has been locked on a revision that is later than the revision of branch B's current Foo.uasset
4. Bob merges main/A into main/B, or cherry-picks the changeset where Alice checked-in Foo.uasset.
5. Bob can now check out Foo.uasset, because the Foo.uasset *revision* on *his* branch corresponds with the *newest* *checkout* of Foo.uasset on *any* branch.

In essence: When you check out a lockable file, it should prevent others from checking it out until they have updated to your check-out's corresponding check-in.

Remember that we don't control when the file is "edited" unless you do a checkout first...

That would be perfectly acceptable indeed. Knowing the file has been already checked out and cannot be checked-in but can still be locally modified.

ok Kamil, it seems too restrictive, you are right....So let's say that a least a pop up window could notify the user that the file he's opening is currently edited by someone else.

I disagree, this makes it impossible for someone to just open a Unity scene (for example), change something to test and move on by undo-ing the work.

"Once changed, a file is automatically exclusively checkout for all users ". I should say more : Once opened/being edited by the user, the file should be automatically exclusively checkout for all users,

Both your proposition make it so that you cannot check-in the file nor version it. That is not the goal.

The user needs to be able to control which types of files can only have 1 unlocked, latest revision, independent of the branch.

Not "one" revision, or no revision (local)

So, basically, it is just about files that:

1) can be changed
2) but won't be checked in at all

If they're not checked in, then of course they won't be merged, correct?

In order to avoid them to be checked in you can use several options:
* hidden changes -> so you just modify them but never checkin.
* a trigger -> to avoid certain file types to be checked in

I still don't see what it has to do with merging.

psantosl,

Well, basically what you're describing is not locking, what you're describing is that you don't want the file to be branched at all, correct??
- No. You still want the user to be able to work on the file while being in a branch. The file will never be merge as only the latest change-set will be unlocked.

The best example is with .unity scenes; the user will save and modify the scene to do its work BUT it doesn't mean he has to commit it. This is very different from working on a .max as its a given that any changes you save, you'll commit it. This is not the case with scenes where you need to save and modify the scene in order to implement other changes.

Well, basically what you're describing is not locking, what you're describing is that you don't want the file to be branched at all, correct??

I mean, as soon as you have several branches and you do not lock concurrently, you'll be able to branch.

You need "foo.max" to avoid any sort of branching, correct??

In order to do that the easiest is to implement a before-checkin trigger so that certain files can't be checkedin on any branch other than main.

Makes sense??

In other words:
- Once changed, a file is automatically exclusively checkout for all users
- Even after "Checking-in", it is still locked for everyone who is not on the same branch
- Only the latest, on the same branch, checked-in version of the file can ever be modified