Wouter

Hi @calbzam We are experiencing the same issue and it's hurting our workflow quite a lot. If we edit any file (even text files) and then update our workspace using the green button in the top-right corner, Plastic will automatically check-out any change we made, even if the file wasn't changed in any of the new changesets. Furthermore there is no option in the GUI to unlock the file without undoing the changes. I've attached a video showing the issue in a small test repo. Version is 10.0.16.6656 Kind regards Wouter PlasticAutoCheckout.mp4

A list of locked items in the GUI would be very nice indeed, including some filtering options. We now use a small program wrapping the command line to an artist-friendlier interface to allow to easily check who has which locks and filtering locks by asset name or path.

I'm just gonna drop this here as well so people coming here can also vote for it: https://plasticscm.uservoice.com/forums/15467-general/suggestions/37148053-go-ahead-and-implement-traveling-locks

Any news on this topic, is it backlogged or should we still expect it some day?

@psantosl Can you provide an update on this topic? It's still a big drawback on our workflow using Plastic and often creates situations where work gets lost because the changes in another branch are not taken into account and are overwritten.

@calbzam We just found out that locks are actually affecting other repositories where the files got pushed to. The locks created in the main repository as well as the 'child repository' (where we push our changes to) share the same identifier (seen in cm listlocks). Even though the listlocks command shows the repository a lock belongs to, Plastic doesn't use that information when handling locks or creating their identifiers. Ideally these identifiers would be repository-and branch-specific.

Hi, 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. Regards, Wouter

Hi 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! Wouter