Amimoller Posted August 26, 2015 Report Share Posted August 26, 2015 Hi, I know this has been brought up before but i still haven't heard a good solution to the problem. On our team we use branches for nearly any task, this works really well for us, its great for collaboration and for committing incrementally as the feature progresses. The problem is unmergeable binary files that we really only want one person to work on at a time (With the intent to commit the changes). As far as i can tell its not possible to ensure this via the lockfile setup in plastic, most of the time it is still possible to checkout a file that has other changes checked in on another branch. It has been suggested to only checkin binary files on the main branch and maybe enforcing it with triggers. But this will prevent you from doing incremental checkins which is one of the main reasons we use plastic in the first place. Since binary files can be anything from images, audio, levels or other data stored in binary by the engine, it is often very nice to be able to checkin smaller changes and only merge back to main when everything is working. I understand a workspace wide checkout may has its own problems, but not having it makes working in feature branches a lot less viable. Which is sad because it a really awesome way to work! Am I just missing something? How do other teams handle binary files, branching and locking? Cheers //Jonas Link to comment Share on other sites More sharing options...
Amimoller Posted September 17, 2015 Author Report Share Posted September 17, 2015 So since no one has replied does this mean we are the only ones with this problem or didn't I explain it clearly enough ? Being able to easily work cross discipline on features in a separate branch until it is done and ready to go into the main branch, is to me one of the biggests strengths of Plastic so i'm curious why no one else are running into these issues. Maybe it only happens when the team reaches a certain size or because we are using Unreal now that has a lot more logic stored in binary files. Any feedback appreciated! Cheers! Jonas Link to comment Share on other sites More sharing options...
manu Posted September 17, 2015 Report Share Posted September 17, 2015 Hi Jonas! how big your team is? I know it's a problem but I think can't find a perfect solution. Imagine the following scenario eventually supporting the multi-branch lock: /main /main/task001 /main/task002 If you lock a binary on "/main/task002" that will prevent other people checking it out at "/main/task001" and "/main/", when you release the lock checking the file in will allow others to be able to lock their loaded revisions of the file and add more changes/revision, that will inevitable end up in a merge scenario will merging "/main/task002" and "/main/task001" back to "/main". A potential solution is the following (please add yours): We can force during the checkout operation that if you don't have the latest revision the co fails. -> In a multibranch environment, which revision is the latest? The one created more recently? Now how do you get the latest revision in your working branch, Plastic is changeset-atomic not file-atomic. You cant merge/cherypick to get that certain file (you could if only the new binary revision is created in the changeset, nothing more, unlikely to happen I guess), we could use the "revert" operation to get the file, it's a dirty way but it would work. All this can be done using the Plastic SCM triggers and some scripting, we can try it together if you want, see if it has drawbacks, if it works fine. Link to comment Share on other sites More sharing options...
Amimoller Posted September 18, 2015 Author Report Share Posted September 18, 2015 We are currently 35 people and growing. Although we haven't all been working on the same project before, that will change soon, so that is one of the reasons why we are looking at ways to reduce conflicts in binary files. We have talked it over some more and what we would like to try is more or less what you described: - In order to checkout a file on any branch, you must have the latest revision and the file cannot be checked out on any branch. - However it should still be possible to checkin files that have not been checked out. (This should be possible as long as you have the latest revision on your branch?) This allows people to work on experimental branches that will never be merged to main and to commit smaller fixes in main while someone is working on the file in a branch. It will be up to the person doing the fix to work with the owner of the checked out file, so that the fix is included in his branch. I can see one case that is a bit weird where you have checked in a file on your branch and then someone checks in a fix on main, you will no longer be able to checkout the file on your branch. Not sure if that can be handled by the trigger. At least its not a showstopper as you can still checkin changes. So conflicts are still possible, but if you have had the file checked out it should be safe to pick your file as it is the owner of the other checkin's responsibility to make sure that his changes won't be lost. It is kindof a software assisted way of asking everyone in the room if it is okay for you to make changes to a binary file, it will require some discipline, but hopefully its better than nothing Link to comment Share on other sites More sharing options...
Amimoller Posted September 18, 2015 Author Report Share Posted September 18, 2015 So I have taken a look at triggers, doesn't seem that complicated. But i'm not sure how this would work. When doing a checkout on a branch should i attempt the checkout in main in the trigger? How do i check that i have the latest revision on my branch? Cheers Jonas Link to comment Share on other sites More sharing options...
manu Posted September 21, 2015 Report Share Posted September 21, 2015 Hi Jonas, don't think I'm not reading this, I'm just thinking Link to comment Share on other sites More sharing options...
tony707 Posted September 25, 2015 Report Share Posted September 25, 2015 Hi, We also try to use the branch per task workflow as much as possible. We are working with Unity and we set up exclusive checkouts for unity scenes (eg big unmergeable binary files). Unfortunately exclusive checkouts does not lock files for every branch... That's why level artists tend to work on the main branch which isn't the best workflow. As a consequence we are facing some merging problems as I reported in this post: http://www.plasticscm.net/index.php?/topic/2515-merge-behavior-on-same-branch/ Looking forward a nice solution too Link to comment Share on other sites More sharing options...
hypotheticalEric Posted October 2, 2015 Report Share Posted October 2, 2015 I'm very interested in this too for the same reasons as you guys. One addition that might be helpful for Amimoller's situation of branches that are never intended to be merged back into main would be to group branches that should share exclusive checkouts. So if branches A, B and C are in a group together, but D and E are in separate groups or their own, checkouts from C would lock A and B but not D or E. Does that make sense? Link to comment Share on other sites More sharing options...
tony707 Posted January 13, 2016 Report Share Posted January 13, 2016 Any updates on this ? Amimoller did you succeed solving this problem with triggers ? Thanks. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.