Jump to content

Preventing locking across branches / forking

Recommended Posts


We are currently working on a project in UE4 using Plastic as our main (and only) source control solution.
Since files from Unreal Engine cannot be merged, we are using exclusive checkouts most files. It happens quite often that we want to test some features or create a slightly divergent version of the project for a demo.

The issue we experience is that doing version control for these branches gets quite annoying. Even though the exclusive checkouts work on a branch basis to check if you have the latest version, it's impossible to checkout or push a file that's already checked out on another branch. This behavior feels weird because the checkout/checkin on the other branch will not affect your current branch in any way. Once it's checked in again on the other branch, your options are exactly the same as before the file was checked out on the other branch.

I may understand something wrong here, but it feels weird to me at least.
So the issue is that branches are never completely separated in terms of checkouts. So making a child branch for a different release or demo with it's own history and locks is not possible as far as I know.
Specifically for our use case, a one-way child branch that's excluded from locking would be enough. Since this is basically a fork, a way to set up forks would also solve this issue.

If this behavior is designed like this on purpose or we simply missed an existing feature, we're open for suggestions on how to set up source control in situations like these.

Thanks in advance!

Share this post

Link to post
Share on other sites


You are right, the locks are only useful if you are working o a single branch (normally working with binary/not mergeable files).
This "single branch + locks" workflow fits good for the artists or developers working with assets (not mergeable files). 
By the way, are you using Gluon? 

If you are going to create branches, it normally means that at some point you will need to run a merge so you are editing text/mergeable files.
We generally recommend removing from the lock rules the files that are going to be modified in the task branches and finally at some point merged.

I guess your scenario is very specific because you are creating branches where you also modify the binary files and you don't plan to merge later?

1) If this "fork" doesn't need to be integrated later, you can push this branch to a different repo where you can perform your changes. This way, the locks from the original repo won't be affecting you.
2) If this "fork" needs to be integrated at some point, you will need to perform the changes on a task branch. And we recommend you to remove the files from the "lock.conf" rules. If you are modifying the files on a task branch, it normally means they are mergeable, so locks shouldn't be necessary.

PD: In the following blog post you can also read some improvements we have on our road map regarding the locks and task branches (your feedback is welcome!):

 Advanced issues found

Distributed locking: Or traveling locks. For example, I want to lock this file on main/task127 but only unlock it when it reaches main (otherwise, as it is today, the lock is not useful unless you are on a single branch). 
This enables branching for teams with lock restrictions (unmergeable content). It goes even further: I lock it, but it should only unlock when it reaches main@centralserver. 
Awesome, isn't it? Game devs love it, but micro-electronics teams too


Share this post

Link to post
Share on other sites


First of, some of the artists are using gluon, although most are using the classic UI because it gives a more detailed view (which is handy IF you understand it).
Secondly the single branch workflow is working out very well for us indeed.
Pushing our branch to a new repository and pulling it in again every time we need to update it will indeed work in our use case since we don't want to merge later on.

Though I find it hard to believe that this isn't a fairly common use case. Even building for different platforms might need changes in settings, shaders and sometimes even logic. For big differences like those, it makes sense to make a new repository and pull in any changes you need. For smaller things though, it might give quite some overload? Making a new repository for each small temporary task might be a bit too much.

While further thinking about this and about the locking system, it makes less and less sense to me why the acquisition of a lock would be global but still the effects of a lock are separated from branch to branch. I'll illustrate with another example:

Firstly note that we do not in any situation want to stop using locks, they are key to making sure no work gets lost.
Suppose we are two weeks before a major deadline but due to some unexpected issues, we still have a whole new feature to implement. Problem: we haven't decided in which of two ways we will make it work. We thus split our dev team of 6 programmers in 2 teams of 3. Each of them will be implementing one of the two ways into the project. Also suppose their changes cannot be merged because, for example, everything is done in blueprints.
The two teams start working on two different branches and keep using the checkout system to make sure they are not editing the same file within their team (and because they are used to using the UE4 plastic plugin to checkout things). But by doing so, they unwillingly block the other team from editing those files at the same time, thus stalling their progress.

I think their are many other use cases where the lock acquisition should not be global and I can't think of any cases where having it global would be useful (although there probably are some but I'm just biased).
Although I can definitely see the use of the distributed locking system, as would make proper feature branching possible. I just don't see why those globally acquired locks are the default behavior currently.


Share this post

Link to post
Share on other sites

Just hit the same issue. Global lock doesn't seem very useful and has a fundamental flaw of not actually preventing conflicts between branches (until "traveling locks" are implemented). We were also planning on branching one way and never merging back at some point, for porting reasons. "Traveling locks" might make that impossible. I suppose we'll look into pushing the branch to a different repo, but it is always nice to have the option to merge later, in case we didn't plan ahead perfectly. 

Ideally locking would be branch specific. For our use case, I'd rather have merge conflicts that I manually resolve for binary files than global locking. Locking is nice for our main branch for day to day work, though.


Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...