Gluon Local Change/Remote Delete Solution

[Downie]

I'm familiar with other SCM but just learning how to use Plastic - specifically the Gluon frontend. During our tests we engineered a situation where a file had been checked-out and changed by A and then deleted by B. As expected this leads to a conflict in Gluon when A attempts to check-in the changed file.

What are the options allowed by Gluon to solve this conflict? We are able to lose the local changes and have the file remain deleted but is it possible to override the deletion with the local content changes and if so how?

[calbzam]

Hi,

In the following web we explain how Plastic is able to handle different complex merge scenarios:

https://www.plasticscm.com/mergemachine

You can especially review the details of the "change/delete" conflict that is the one you are commenting. 

Regards,

Carlos.

[Downie]

@calbzam Thanks for the link. The documentation explains how this is possible using the Plastic front end, are the same resolutions possible using Gluon alone?

[calbzam]

From the Gluon GUI, you cannot configure the permissions, you will need to use the regular GUI or command line. But then the permissions will be applied to the different users doesn't matter the GUI they are using.

Regards,

Carlos.

[Downie]

11 minutes ago, calbzam said:

From the Gluon GUI, you cannot configure the permissions, you will need to use the regular GUI or command line. But then the permissions will be applied to the different users doesn't matter the GUI they are using.

Regards,

Carlos.

Think that might have been applicable to a different post, so my question about resolving the conflict in Gluon probably still stands. Ideally we wouldn't want the art team to have to switch from Gluon to Plastic in order to solve delete conflicts

[calbzam]

From Gluon you can also solve conflicts via merge but it doesn't fit very good with the Gluon philosophy. The artists using Gluon should be working on a single branch using locks (exclusive checkout). This way, they will never face any conflict and the workflow is very simple (no conflicts to solve).

If you need a more advanced workflow for developers creating branches and integrating them via merge, they can use the Plastic GUI including all the advanced features. If you request the training, we can review in detail the Gluon vs Plastic GUI workflow to check what fits better for your needs.

Regards,

Carlos.

[Downie]

17 minutes ago, calbzam said:

This way, they will never face any conflict and the workflow is very simple (no conflicts to solve). 

I was able to engineer the conflict using Gluon alone on a single branch/centralised server model - even though the file was checked-out and was setup as exclusive checkout on the repository it was still possible to delete the file while it was checked out. Ultimately the art team will be checking the checked-out status of files before deleting them but it seems Gluon still allows this case to occur and mistakes happen so just wanted to check if there was a mechanism for solving it.

[calbzam]

Ok, sorry, I fully understand now. The lock (exclusive checkout) was designed to avoid merge conflicts on binary files (impossible to be merged). That's why in this case the lock is not applied. You can always delete a file, even if it's locked by a different user (but you can't checkin new changes for this file).

Gluon only supports file merge conflicts (via mergetool) while the Plastic GUI fully supports advanced directory conflicts like the one you are mentioning.

In Gluon you will see a panel like the following:

Regards,

Carlos.

[Downie]

Yeah that's the conflict panel we see. It seems to suggest there are 2 options either to "undo your local changes" or "restore the item....". Can the user who is experiencing the conflict restore the item to the server from within Gluon and the proceed to check-in their work?