Switching branches with changed items

[Rhys]

When a workspace has pending changes and the branch it is on has newer commits, the GUI provides the View New Changes button, allowing the changes to persist and resolve against the changes made. This is useful, as it doesn't require a new changeset to be created and local changes are retained.

Does such functionality exist for branch switching? Often in our workflow, there are a common set of changes that can occur locally that prevent us from discarding if we want to switch to a neighbouring branch. It seems that such a workspace change would follow the similar process of resolving the changes without necessitating a commit, is that correct? Possibly a command line option could resolve this outside of the GUI also.

[calbzam]

Hi,

The problem when switching your workspace with local changes is you can end up facing problems like the following:

https://plasticscmsupport.zendesk.com/hc/en-us/articles/360014970894-The-parent-revision-of-the-item-is-inconsistent-with-the-loaded-one-in-changeset-cs-xxx

That's the reason why we don't allow by default to switch your workspace with local changes (although it's up to you to enable it).

Not sure if you are aware of the "shelve" feature (also the "checkin changes to a different branch"). They can also be useful in scenarios like yours.

Regards,

Carlos.

 

[Rhys]

Thanks for the clarification, Carlos. I am still a bit confused as to how the operation would be different to a stash > switch changesets > unstash approach, but I might be missing something in that article.

Stashing itself would also be convenient, but from my understanding our Cloud account does not provide this, though I may be mistaken. For the purposes of not committing this in-progress project state, "checkin changes to a different branch" doesn't seem to fit to bill too well for this scenario for us.

[calbzam]

You are right, the stash (we call it shelve in Plastic) is not still supported for cloud repos (only local ones).  Let me understand a little bit more your workflow:

- If you are creating task branches, I guess you are developers (I mean working with source code, not binary assets that then you won't be able to merge). As a developer using Plastic Cloud edition, you can also work distributed, hosting your local repos and then pushing/pulling to the cloud. I guess at the moment you are working fully centralized (your workspaces directly pointing to a cloud repo).

Quote

I am still a bit confused as to how the operation would be different to a stash > switch changesets > unstash approach, but I might be missing something in that article.

- When you create a shelve, you are creating a temporary changeset and when you apply the shelve, you are actually running a merge of this temporary changeset with your workspace content (resolving the conflicts if necessary). That's why following this workflow you won't end up in an issue like the explained in the article:

https://plasticscmsupport.zendesk.com/hc/en-us/articles/360014970894-The-parent-revision-of-the-item-is-inconsistent-with-the-loaded-one-in-changeset-cs-xxx

Regards,

Carlos.