Wolfram Posted July 23, 2018 Report Share Posted July 23, 2018 Hiho. Generally, in our team different people are working on different branches. But quite often it also happens and/or is necessary that two people work on the same branch, or at least that somebody needs to commit something (=hotfix, necessary update, ...) in "somebody else's" branch. What usually happens in these cases is, that both users start off at the same changeset, say cs:100. User A therefore has pending changes on 100. Now user B commits something as cs:101. As soon as user A now tries to commit his changes, he will get notified that there have been changes on his branch, and that a merge is required (with a dialog giving only two choices: "merge NOW" and "commit in new branch"). Now, this makes perfect sense and is completely understandable that this is mandatory if some assets have been modified by both, no matter whether any conflicts could be resolved automatically, or had to be resolved manually. In these cases, the info that somebody else modified the same assets and user A originally started from an older changeset must/should be represented in the branch explorer, as merge links within the branch, as it is done by PlasticSCM at the moment. However, if the modified assets/files are different so that there are NO CONFLICTS at all (not even automatically resolvable ones), as in "user A modifies script1.cs, user B modifies script2.cs", there really shouldn't be any need to manually enforce a merge, mixing up both merge result and local changes in a single changeset, and cluttering the branch explorer with many "unnecessary" merges of completely intependent changes (see snapshot). To prevent this, the tedious and complicated workaround is, to undo/cancel the merge (if at all possible, as changed assets may have been mingled?), to store all pending changes in a shelf and undo them, to manually update the branch to the new head, to re-apply the shelf, to cleanly commit the changes, and then to delete the now unnecessary temporary shelf. Yuck. Instead it should suffice to silently update user A's branch to the latest changeset, or at least give him that choice as a third option in the warning dialog, i.e. "automatically switch to branch head and commit from there instead". So user A's client would notice there is a new cs:101, but it is completely unrelated to the changes user A is trying to commit. So the client simply updates to cs:101 in the background, and then does a regular commit from this new base. I am also pretty sure that this WAS exactly the behaviour a while ago (some time last year?), and it was extremely convenient. 1) So I'm wondering why this behaviour was changed, and now the mandatory, "complicated" merge is now enforced? Maybe there is also a configuration option to revert back to the old behaviour? 2) As a side note, the main preferences setting "Diff and merge"=>"Allow to merge with pending changes" never(?) had any effect for us, I don't see any different behaviour whether this is on or off, it always behaves the same (at least in the forced-merge scenarios described above). What EXACTLY is this toggle supposed to do? 3) As ANOTHER side note, if you have pending changes, in the past the Branch Explorer will show you this as a new, virtual changeset with a dashed border. This feature seems to have been broken (again, for several moths now already, at least), as most of the time there is now no visual difference in the branch explorer between "pending changes present" and "clean workspace", even after refreshing the Branch Explorer, or restarting the client. Although I still DO see the dashed marker around my home icon from time to time, but I'm currently not sure under which exact circumstances (or whether it's deterministic at all). Any ideas? Thanks! Wolfram Link to comment Share on other sites More sharing options...
calbzam Posted July 23, 2018 Report Share Posted July 23, 2018 Hi, The update-merge operation should only require a merge if there is a conflict. If there is no conflict with the head of the branch, you should be able to update your workspace to the last and finally checkin your changes. Now let's try to understand why it's not the behavior you are experiencing: 1) Are you using "cloaked.conf" rules in your workspace? 2) "Allow merge with pending changes" --> It allows to you to run a merge when you already have some pending changes in your workspace. By default, it's disabled so the users are enforced to commit their pending changes before running a merge. This way, we avoid issues undoing changes to Plastic newcomers (you will need to undo all your pending changes after running a merge). This setting shouldn't be related to the issue you are facing? 3)If you checkout local your files, there should appear the virtual changeset in the "Branch explorer" view. Regards, Carlos Link to comment Share on other sites More sharing options...
Wolfram Posted July 23, 2018 Author Report Share Posted July 23, 2018 Hi Carlos, Quote The update-merge operation should only require a merge if there is a conflict. Glad to hear it! Unfortunately, that's not what we see. Quote If there is no conflict the head of the branch, you should be able to update your workspace to the last and finally checkin. What exactly do you mean by this? If I try to update either via the "Update Workspace" button in the Workspace view, or the "Switch workspace to this changeset" menu in the Branch explorer, I get the usual "cannot update since there are pending changes" error. So how can I switch to the branch head for a workspace with (unrelated) pending changes? Quote 1) Are you using "cloaked.conf" rules in your workspace? Yes we do, but the specified files do not match/affect the files or directories modified by either user A or B. Is that a problem? Quote 2) "Allow merge with pending changes" --> It allows to you to run a merge when you already have some pending changes in your workspace. By default, it's disabled so the users are enforced to commit their pending changes before running a merge. This way, we avoid issues undoing changes to Plastic newcomers (you will need to undo all your pending changes after running a merge). This setting shouldn't be related to the issue you are facing? Not sure, I thought I should mention it as the update-merge DOES merge changes from cs:101 into the local pending changes of user A before he is allowed to commit them, INDIPENDENTLY of this flag, although it should prevent(?) such a merge if it is off, from my understanding, and from your description. Quote 3)If you checkout local your files, there should appear the virtual changeset in the "Branch explorer" view. Unfortunately, hat's no longer what we see. It worked nicely in the past, but not anymore. Unfortunately I'm not sure since when this is broken. See the two attached snapshots of the same workspace (i.e., one containing pending changes). Link to comment Share on other sites More sharing options...
Wolfram Posted July 23, 2018 Author Report Share Posted July 23, 2018 Quote If I try to update either via the "Update Workspace" button in the Workspace view, or the "Switch workspace to this changeset" menu in the Branch explorer, I get the usual "cannot update since there are pending changes" error. Correction: I noticed there is another setting ion the global preferences for this, "Other options"=>"Behaviour when trying to switch...". This was set to "do not allow", producing the error dialog. However, if I set it to either "Allow" or "Allow, show a warning" (and press "Continue" in the dialog), it still claims "Some files you have changed in your workspace have been modified as well...", and continues with a merge window, although the locally modified file is NOT affected by the new changeset. Link to comment Share on other sites More sharing options...
calbzam Posted July 23, 2018 Report Share Posted July 23, 2018 Hi, 1) I'm afraid you will need to disable the cloaked rules in your workspace if you want to use the update-merge feature: This way, when you are checking-in your changes, you will not be forced to merge but you can just update your workspace first and then checkin your pending changes. 2) I can give it a try, but this setting was designed for scenarios where you are running the merge. For the update-merge, it makes sense that you can perform the operation. Your problems seem to be generated by the "cloaked.conf" rules. Anyway, I will double-check the behavior of the update-merge operation with this setting. 3) Your workspace contains local changes, but the files are not checked-out. If you checkout the "honk.cs" file, could you check if the virtual changeset is appearing in the "Branch explorer" view? Regards, Carlos. Link to comment Share on other sites More sharing options...
Wolfram Posted July 23, 2018 Author Report Share Posted July 23, 2018 OK, we don't really need the cloaked.conf, and after removing it it now works as expected, thanks! ? Quote 3) Your workspace contains local changes, but the files are not checked-out. If you checkout the "honk.cs" file, could you check if the virtual changeset is appearing in the "Branch explorer" view? Hm, it is indeed, but we have been working with Plastic for almost two years now, and we NEVER used the Check-out/Check-in functionality (and in fact your own documentation suggests this workflow ? https://www.plasticscm.com/documentation/technical-articles/no-checkout-workflow.html ). However, in the past the virtual changeset was still always(?) correct, but now it no longer is. Any ideas? Or looking at it from the other side, would it be possible to have the Branch Explorer show the virtual changeset even if files are "only" marked as "Changed", and not as "Checked-out"? Link to comment Share on other sites More sharing options...
calbzam Posted July 24, 2018 Report Share Posted July 24, 2018 Hi, great to know it is working now. It's not necessary to a follow checkout/checkin workflow. You can use a locally modify/checkin workflow. According to the branch explorer legend, the dots represent a checkout changeset and I think this behavior was not recently changed. Regards, Carlos. Link to comment Share on other sites More sharing options...
Wolfram Posted July 24, 2018 Author Report Share Posted July 24, 2018 Ah, ok. Maybe I remembered wrong. I'll add this as a feature request then, though. Or is there an important reason why one would NOT want to mark pending changes (or why one would have to differentiate between checked out and changed files here)? What happens in our team all the time is: Open the branch explorer, see everything is in order, try to switch the branch (for example, by creating a new one and autoswitch), get an error that switching is not possible, click OK, undo the branch creation because I want to commit the changes first, and so on. BTW, how do you display the legend? In the past there was a button for this, but my client no longer shows this (I thing since 7.x?) ...NVM, I just found it hidden in the help text you get when clicking the lifebuoy. Link to comment Share on other sites More sharing options...
Wolfram Posted July 24, 2018 Author Report Share Posted July 24, 2018 14 minutes ago, Wolfram said: I'll add this as a feature request then, though. For reference: it's now here: https://plasticscm.uservoice.com/forums/15467-general/suggestions/34913716-have-the-dashed-marker-in-the-branch-explorer-for Link to comment Share on other sites More sharing options...
calbzam Posted July 25, 2018 Report Share Posted July 25, 2018 Hi, In order to make this behavior not only for checked-out items (but also for locally changed items), it would be technically more difficult. The information regarding the checkout items is automatic. The local changes detection is customizable by the user and this operation could take long time in big workspaces with tons of locally changed items. It would mean the branch explorer refresh operation to also take longer...Anyway, we appreciate your feedback and I will share with the team your request. In order to display the branch explorer legend, on the top-right, there is an "Information" icon. If you click on it, you can then select "toggle the diagram legend". Regards, Carlos. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.