Allow update-merge on "Update Workspace" and "Switch"
Back in old Subversion, the scenario of "Updating to a newer changeset (on the current branch) while there are Pending Changes in the workspace" was handled very smoothly and seldom caused any problems. (Sure, conflicts can arise but they are usually minor since we are on the same branch.)
I'm aware that it's recommended that each developer works on their own child branch. Nevertheless, this situation comes up, for example when two child branches are being concurrently merged back to the parent. Also, the Plastic team has already put some work into supporting this scenario:
"While our recommended pattern is definitely branch-per-task, sometimes you’ll find yourself sharing a branch with another developer or even the whole team."
Unfortunately, the current handling of this scenario is not optimal. There are (at least) 3 methods for updating the workspace to the latest contents on the current branch, and the third method differs from the first two in ways that are hard to predict:
(1) Pressing "Update workspace" button on the Items view.
(2) Switching to the same branch.
(3) Pressing the "View new changes" button that appears in the Pending changes view when there are newer changesets.
The setting "Other Options - Behavior when trying to switch / update with changed items" / PendingChangesOnSwitchAction controls some aspects regarding the behavior of method (1) and (2). When using the "No-Checkout" workflow, it has been recommended to choose the option "Allow" or "Allow, showing a warning" for this setting. However, in my experience this does not work well at all. This setting only affects Changed files and it causes several problems, even potentially blocking a subsequent Checkin! On the other hand, the default option "Do not allow, show an error" will prevent any attempt to use method (1) and (2) when there are local changes. Also, if there is any checked-out items, method (1) and (2) will be disallowed regardless of settings.
(Details: If I switch/update with locally Changed files with the above option "Allow, showing a warning", I get the Confirm Update dialog. If I then choose to continue with the Update, I get the Update Results dialog. Here, my Changed files are listed as "not up-to-date" even if the new changesets on my branch contained only changes unrelated to these files! And if the new changesets on my branch did contain changes related to my changed files, I may even become unable to Checkin because of an error "parent revision is inconsistent with the loaded one"! Also, if I use "Update forced" I would lose my local changes.)
Method (3) is only available if we have activated "Look for newer changes in the repository" under Options in the Pending Changes view. This method is working much better, since incoming changes are handled by a sub-branch-merge.
(NOTE: When cloaking is active, the method (3) will always cause a Merge instead of an Update if there are newer changesets, potentially leading to unnecessary "sub-branching" even when there are no changes in the workspace!)
My suggestion is to:
- Completely remove the setting "Behavior when trying to switch / update with changed items"
- Handle "Switch" and "Update Workspace" (method 1 and 2) very similar to "View new changes" (method 3).
This would make the handling much more consistent. Both Changed and Checked-out items can then be merged, and a trivial switch/update can be performed if there are no conflicting files.
I've voted 3 votes on this. I agree with Göran that the update process should be unified. In my eyes, the option (3) is currently the only appropriate one for updating workspaces with local changes. But it doesn't help for branch switching.
I often find our developers to be forced to shelf and update/switch and then unshelf again because they have local changes which require a merge. This can result in huge changelists, when someone has integrated another branch (hundrets of files have changed) and just one single file matches my local changes. The result is a huge changeset although I might be introducing a few lines of code only.
I think the shelve + switch/update + unshelf workflow should be available as on-the-fly-solution in the GUI without introducing branch-local merge links. I'm thinking of rebasing my local changes onto the latest version of the repository.
Göran Wallgren commented
REPLY: When I said "it has been recommended", I actually meant "recommended by Codice staff" (!) See these recent answers on the forums:
So much for TOTALLY discouraging the use of this setting... ;) There is NO mention of side-effects in these answers!
IMHO, since this setting causes so much potential headscratching, it would be better to remove it and instead unify the Update methods.
It's also very confusing to _not_ have the same behavior whichever way the user chooses to update the workspace. Using method (3) everywhere would also make it much simpler to carry pending changes over to another branch (no need to shelve). In Subversion we could do that as well...
In your answer, what does (also triggered by "2") mean? It would seem to indicate that method (1) and (2) are not fully identical after all, but maybe it means something else?
"When using the "No-Checkout" workflow, it has been recommended to choose the option "Allow" or "Allow, showing a warning" for this setting"
Well, indeed, this is TOTALLY discouraged.
You should never leave changes behind unless you're really sure of what you are doing. What does it mean? If any of the files you left in your workspace with changes is meant to be checked in later on, chances are you will be in trouble if the loaded revision doesn't match the revision that should be really loaded.
This is because how merge tracking works. Merge tracking works on a changeset basis, not a item per item basis (as older versions and ancient version controls used to do). So, if a revision doesn't match the one that should be loaded on the working changeset, you can't checkin, because you would be overwriting newer changes and there's no way to merge them.
But, there are times when files that are not meant to be checked in (like config files, log configuration files, debug files, etc) should stay around during an update or switch to branch. That's why we have introduced this setting. It can be used for other scenarios but it requires a deep understanding of what is happening behind the scenes.
Onto more of your topics: scenarios (1) and (2) are exactly the same one, no differences.
Scenario (3) is what we call "update-merge" (also triggered by "2"): it basically makes sure you can go to the latest changeset, and moves the checkouts to the latest in case there aren't conflicts.
Anyway, thank you for the feedback. This is not a cheap change, initially, so let's see how interesting it is for the rest of users out there.