Undo check-out without loosing changes

[JakubH]

Hi,

after some time I return back to evaluation of Plastic SCM. And I run into this problem:

I make some changes in a file, but I don't want to check-in it. For example because I add only some temporary debug stuff. But after that I want to get some new changes from others, so I want to update or switch to the last changeset. I can do that, but only if I didn't check-out my changes. As soon as I check-out (or Plastic SCM or Visual Studio plugin do that for me), I have only one way – to undo check-out. But this deletes my changes, which is what I don't want to. What I need is to remove the "check-out flag" only.

Similar issue occurs with hidden changes. It seems to me that a "check-out flag" overrides a "hidden change" flag. And I can't get rid of it, unless I lose my changes.

[carpediemevive]

When I run across this I usually just shelve my changes, update my workspace, and then re-apply my shelf to my workspace. If you really want you can then delete the shelf as these do exist on the server.

[manu]

As carpediemevive says you can use the shelve operation to "backup" your changes and apply them later in a different branch. The shelve can be also used along developers.

[JakubH]

Thanks for your answers.

But I am still not very happy about that. Imagine following scenario:

I have some debug code inside a file in my workspace, which I won't check-in (either now or in the near future). However I want to get changes from my coworkers, even in the same file.

It seems to me, that the only option I have is to shelve my debug code and un-shelve it after every “Merge from this changeset” or “Switch to this changeset” command, which every time leads to merge with manually solving the same conflict. And what is even worse, I have to undo this merge before I can do any change in any file! Because if I didn’t undo it, I couldn't undo it later without losing my other changes – partial undos are not allowed when there is a merge.

The result is that in the given scenario, I am doomed.

The behavior I’d like to see is this:

I shelve the debug code, but leave those changes in my workspace and set the file as a hidden-changed. When I want to get last changes from my coworkers, I switch to the last changeset or (in case I have had my own changes already) I merge from the last changeset. After that I can check-in my changes, which would ignore the hidden file.

In case I want to check-in some other changes within that file, I perform a subtractive merge from the shelf (not possible nowadays; from UI at least) to delete my debug code temporarily, I unhide the file and check-in. After that I can apply the shelf to get my debug code back.

[anuar]

Hi JakubH,

There are some options in Plastic that could be useful for you.

Go to the left panel and click on "Preferences" -> "Other options".

- See "Behavior when trying to switch / update the workspace with changed items" options: if you set it to allow, you will be able to switch your workspace and changed items will remain in your workspace.

- In addition take a look to "Find changed files in workspace before Merge" option, it could be useful to you too.

Anyway, I encourage the use of task driven development, in a branch per task pattern, that avoids all these kind of problems when developing. You can find a brief introduction in the "Intro" section of the Plastic Quick Start:

http://www.plasticscm.com/infocenter/quick-start.aspx

regards,

Anuar

[JakubH]

Thanks for your quick answer.

- See "Behavior when trying to switch / update the workspace with changed items" options: if you set it to allow, you will be able to switch your workspace and changed items will remain in your workspace.

Yep, I have set "Allow, showing a warning". But this doesn't help in case I've checked-out or if I want to merge external changes with mine.

Anyway, I encourage the use of task driven development, in a branch per task pattern, that avoids all these kind of problems when developing.

Yes, a strict branch-per-task pattern would avoid that. I am just trying to evaluate what is possible in Plastic SCM to present it in our company. The scenario described is not mine actually, but it is common for my colleague. I'll suggest him to use branches for that. However some of my suggestions (undo a merge only, subtractive merge from a shelf) could be still useful.

[anuar]

Hi JakubH, I know this is not exactly what you want, but may be could be suitable for your company the use of a branch per developer pattern. So each user can check his changes in whenever he want, and merge or subtractive merge for any changeset in his own branch.

[JakubH]

Yes I think it is obvious that we have to change our habits and work a bit differently than with CVS, if we want to move to Plastic or any other modern SCM. I am fine with that, but it might be more difficult to convince the others. ;-)

[anuar]

I hope you succeed in it Then you will be able to take advantage of all the features of Plastic but, else, I think Plastic can still be a good choice.