Branch-renaming caveats

[Francois Bertrand]

Hi!

We have run into issues in the past renaming branches, where some clients "lost track" of a branch they were on when checking back in.

I forget the exact issue but it was related to branch-tracking seemingly using names as the key.

When is it not safe to rename a branch? (e.g. when someone else is working off of it? when there is a merge in progress or if there will be a merge in the future? etc.)

We would like to rename branches on our project but we want to make sure no client gets errors.

Thank you!

Francois

[calbzam]

Hi,

If you rename a branch and there are other developers whose workspaces are pointing to the original branch name, they will get an error if they try to checkin changes because the checkout branch name doesn't exist anymore. They will need to update the workspace selector to point to the new branch name.

Regards,

Carlos.

[Francois Bertrand]

Got it, thank you.

I know it's probably not a trivial change, but as an end user that feels broken and causes confusion. Looks like basic use of the "rename branch" functionality can cause direct errors that are not explicitly explained. (we had people freak out when their workspace was all of a sudden broken!) Perhaps prohibiting renaming a branch if any other workspace is pointing to it would be an answer?

Thanks again. I know I've been hammering you guys on the forums but we use this tool every day and hopefully it helps build a better product.

Francois

 

[Francois Bertrand]

I just wanted to bump this.

This is making branch renaming a hazard; we don't rename branches that often, but when we do we never know if we might break someone's workspace completely. Are there any fixes planned?

Again, thank you; we just want to make Plastic as robust as it can be!

Francois

[calbzam]

We just released a new feature so if somebody deletes/renames the branch you are working, you can still undo your local changes so your workspace is not broken anymore:

 

[Bug] 8.0.16.3433
All platforms - Plastic, Gluon: We improved the behavior when you have local changes and the changeset loaded in your workspace is deleted by a different user.
Before these improvements, this meant that you got stuck: at that point you were unable to checkin, shelve or undo your local changes.
We modified the client behavior to enable you to undo your local changes, letting you out of that loophole. Shelving or checking them in will still be unavailable, as they wouldn't have a parent changeset.
The 'undo' behavior will be slightly different depending on the client you use:
Gluon will always allow you to undo the local changes. If the original contents aren't available anymore, the head contents of the current branch will be used instead.
Plastic, on the other hand, will notify you about the inconsistency and then ask you for confirmation to undo all your local changes and update the current workspace.

Regards,

Carlos.

[Francois Bertrand]

Hello Carlos,

Thank you for listening to your customers' feedback!  This is great and hopefully makes Plastic better.

Cheers,

Francois