Stuck: can't commit or get rid of merged changes

[Wolfram]

Hiho.

Just starting with PSCM, so we created a test repo to experiment and "get to know" the system.

What I did:

- I understand it is not possible to switch between workspaces due to pending changes. So I wanted to create a branch for those, as they were not supposed for the main branch.

- So I used "Checkin changes to a different branch", as /main/WKtest2. I also checked "Do not checkin changes, just move..." - although I later realized that this probably wouldn't solve my problem: it would just create a new workspace with the same pending changes. However, we exclusively used a pure serial VCS (=single branch) in the past, so I'm still very reluctant over committing anything that is not "final". My understanding is that this concept no longer holds (or is the best approach) in PSCM? Can anybody shed some light on this?

- Then I accidentally did the same again: I created ANOTHER branch as sub-branch, /main/WKtest2/WKtest2, moving these pending changes over there (so they were no longer in /main/WKtest2, from my understanding?)

- This was not what I wanted. So I wanted to get rid of this sub-branch, but needed to move the changes back to /main/WKtest2. Any insights on what is the best approach for this?

- Well, I somehow managed merged these changes into my actual branch /main/WKtest2, but I had to commit them first as cs:26 in /main/WKtest2/WKtest2

- After the successful merge, I deleted the branch /main/WKtest2/WKtest2 which I definitely did not want having around, as it was created by mistake.

- For this, I also had to delete cs:26.

- But now I'm stuck (see snapshot): I now have a pending merge link, which practically ENFORCES a commit of unfinished stuff before I can do anything else. - BUT I cannot commit these merge results, as the original changeset (=from the deleted branch) no longer exists!

 

How can I recover from this, without losing the changes I made (=everything that's currently marked as pending change)?

[psantosl]

Hi Wolfram,

 

Quote

> - I understand it is not possible to switch between workspaces due to pending changes. So I wanted to create a branch for those, as they were not supposed for the main branch.

 

Well, you are using “workspace” when you actually mean “branch”.

 

A workspace is just a working copy. It is a directory where you download code to work with. You can have as many workspaces as you want to work on the same repo, or only one, up to you. Workspaces download a branch, that’s true, but there is not a 1-1 relationship between the two. You can *switch a workspace to a different branch* at any point.

 

Quote

> - So I used "Checkin changes to a different branch", as /main/WKtest2. I also checked "Do not checkin changes, just move..." - although I later realized that this probably wouldn't solve my problem: it would just create a new workspace with the same pending changes.

 

It actually creates a new *branch* not workspace ;-)

 

Quote

> However, we exclusively used a pure serial VCS (=single branch) in the past, so I'm still very reluctant over committing anything that is not "final". My understanding is that this concept no longer holds (or is the best approach) in PSCM? Can anybody shed some light on this?

 

Yes, IMHO you are better served by branches and super frequent checkins.

I’m working on something, like “add a new compression method for binaries in Plastic”, so I create a branch for it. The branch will start from a well-known stable point, a label (that has been tested, reviewed, worked in production and so on).

Then I switch to the branch.

I make a change, and I check-in. Yes, I will be creating many checkins, tons of them. I find myself checking in every 5-10 minutes. I tell a story of how I made my change, so it ends up being much easier to review later on by my colleagues, because they can walk the branch cset by cset if they want to, instead of having to understand the whole change completely in a single step. But that’s me… so there are other options.

Anyway, using your task branch to checkin super often is good. Take advantage of it. You can merge the branch when you are done.

Thanks to that, now the version control is no longer just a delivery mechanism you use when you are done, now it is something working for you, helping you. You can diff changes you made 20 mins ago, anything.

 

 

Quote

> - Then I accidentally did the same again: I created ANOTHER branch as sub-branch, /main/WKtest2/WKtest2, moving these pending changes over there (so they were no longer in /main/WKtest2, from my understanding?)

 

Wow! That’s a good one ;-) Yes, most likely they are no longer on wktest2, but in the child branch :-)

 

Quote

> - This was not what I wanted. So I wanted to get rid of this sub-branch, but needed to move the changes back to /main/WKtest2. Any insights on what is the best approach for this?

 

We don’t have a “move changes to a different branch” yet, but it will be there soon: https://plasticscm.uservoice.com/forums/15467-general/suggestions/3742293-move-changesets-to-different-branch it is the top 1 at this point in our UserVoice.

 

Once we have it: simply checkin to your branch, later move the changesets. That’s all.

 

Now: well, your changes are now on the branch… is not like if they were private. You can shelve them (as I answered before in another question you asked) and apply them to the previous branch later.

 

Quote

> - Well, I somehow managed merged these changes into my actual branch /main/WKtest2, but I had to commit them first as cs:26 in /main/WKtest2/WKtest2

 

Well, that’s an option, yes.

 

Quote

 

> - After the successful merge, I deleted the branch /main/WKtest2/WKtest2 which I definitely did not want having around, as it was created by mistake.

> - For this, I also had to delete cs:26.

> - But now I'm stuck (see snapshot): I now have a pending merge link, which practically ENFORCES a commit of unfinished stuff before I can do anything else. - BUT I cannot commit these merge results, as the original changeset (=from the deleted branch) no longer exists!

> How can I recover from this, without losing the changes I made (=everything that's currently marked as pending change)?

 

 

Yes, this is a weird situation indeed. You deleted the source of the merge while the merge was in progress… something definitely not usual, and it seems we are not protected against it.

 

Try to shelve the changes (not sure if it will work in your scenario, I think it will). Then undo your changes. Then apply the shelve and you will be done.

 

Let us know if it worked :-)

 

And, please, don’t worry, you won’t be doing this strange “moving things around branches” often later on

[Wolfram]

Hi pablo,

thanks a lot for detailing the usefulness of the branching concept! Guess we will have to significantly change our workflow, to make use of its advantages! :-)

On 11/11/2016 at 7:59 PM, psantosl said:

Well, you are using “workspace” when you actually mean “branch”.

You're right, of course. I was aware of the difference when writing the post, but used the wrong word. However, this:

On 11/11/2016 at 7:59 PM, psantosl said:

You can *switch a workspace to a different branch* at any point.

contradicts the behaviour, as my original problem was that I could NOT switch my workspace to a different branch when it contains pending changes (which was essentially ALWAYS the case with our workflow in the past). Was that a typo, or am I still missing something?

On 11/11/2016 at 7:59 PM, psantosl said:

Yes, this is a weird situation indeed. You deleted the source of the merge while the merge was in progress… something definitely not usual, and it seems we are not protected against it.

Try to shelve the changes (not sure if it will work in your scenario, I think it will). Then undo your changes. Then apply the shelve and you will be done.

Let us know if it worked :-)

Well...yes and no...

The shelving broke the pending merge link connections, as intended. So I could discard/undo the merge, and re-apply the shelf.

However, somewhere along the way the actual file contents were lost. All files originally affected by the merge were still listed, but their file sizes were 0. :-/

Ah well, good thing this was just a test repo ;-)

[psantosl]

13 hours ago, Wolfram said:

contradicts the behaviour, as my original problem was that I could NOT switch my workspace to a different branch when it contains pending changes (which was essentially ALWAYS the case with our workflow in the past). Was that a typo, or am I still missing something?

Actually, you can switch but not when there are pending changes :-)

 

What I mean is that the workspace is not *tied* to the branch in any way, you can switch it (unless you temporarily have pending changes).

 

 

There is an option to let you switch with pending changes, but I totally discourage it until you get much more familiar with the tools.

 

 

Onto the "deleted merge thing": this is a case we should protect. I mean, we should throw a controlled exception instead of failing. Not a usual case to delete the source of a merge while the merge is in progress, by the way, but not an excuse :-)