Jump to content


Locking files all the way up upstream

Lock Stream

  • Please log in to reply
No replies to this topic

#1 QHovey

QHovey

    Newbie

  • Members
  • Pip
  • 2 posts

Posted 20 December 2019 - 07:11 PM

I have a very common problem with game development source control when it comes to artist and designers working on non-merge able assets. They can not work in task streams because the same file can be checked out in two or more task streams. The first one to merge back to Mainline wins, everyone else has to redo work.

I am looking for a very simple solution that would involve task streams obtaining a file lock that propagates up to it's parents recursively until it hit mainline. Just for extra clarity here is an example with an extra sub task.

Mainline
   MainTask
	  SubTask
  • SubTask requests to checkout a file.
  • It asks MainTask for the file
  • MainTask doesn't have it locked so it asks Mainline for the file.
  • Mainline doesn't have it locked either, so it locks the file and gives the lock to MainTask.
  • MainTask locks the file and gives it to the original requester SubTask.
This is just simple recursion. Now lets undo this.

SubTask commits the file to itself for history. SubTask STILL OWNS THE LOCK! The lock is only released back to MainTask after SubTask copies up to MainTask. Likewise for MainTask to Mainline.

If anyone else requests the file, they will get blocked, usually because Mainline blocks them for having it locked. Let's go a bit deeper

	  Mainline
   Task1	  Task2
Task1a	   Task2a	Task2b // - Owns FIle lock
  • Task1 and Task1a can't checkout the file cause the recursive lock check hits Mainline who has it locked
  • Task2a can't checkout the file because Task2 has it locked.
Now here is the extra bit of spice. Streams can own the lock, but the file can still be not-checked out by a user. We saw a bit of this with SubTask committing the file for it's history, but still owning the lock.
If Task2b merges and copies up to Task2, then Task2a can now checkout the file. To do so they will be required to merge down the latest version from Task2, and no one on Task2 has it checked out.
So in summery, a stream may only give a lock to a child stream if it owns the lock of the file, and the lock isn't currently checkout. Task1 streams got blocked by Mainline because it doesn't own the lock, Task2 does.

Really need this, like years ago.





Also tagged with one or more of these keywords: Lock, Stream

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users