The parent revision of the item <filename> is inconsistent with the loaded one in changeset cs:xxx

[LoganBarnettASU]

Hey guys,

Occasionally we get this error. It usually seems random since we're not doing any kind of branching/merging, and it doesn't happen consistently. Once it happens though, it stays that in an erroneous state. Sometimes we can shelve and reapply the shelve immediately in order to correct the issue. This time we weren't able to correct the behavior. I was able to move on by sending the file over to another machine and committed it from there without issue.

I've left the first machine stuck in the error state in case there's something you'd like us to try or some logs we can pull up. Any ideas?

Screenshot attached showing the error.

Thanks in advance!

[manu]

Hi Logan,

let me explain, with an example, why this situation is happening.

Imagine that you are working in a changeset that loads the revision #500 of the "foo.c" file. Then, you change this file but without checking it out. So you have the revision #500 of the "foo.c" file changed.

Now you switch your workspace to a different changeset, due to an update operation or a switch to branch/changeset operation, this new changeset is loading the revision #555 of our changed file, but you are still having the revision #500 changed.

When you try to commit the "foo.c" file Plastic is going to identify that the parent of your changed file is not the one that it's supposed to be. Instead of having, as the parent of the changed file, the revision #555 we have the old one, the #500.

Why we throw the error? Due to it's a safe way to prevent from code regressions. Imagine that the revision #555 contains a bug fix that it's not present in the revision #500, if you finally commit the changed item the bug fix is lost....

It also can happen if you have the item as changed and then you perform a merge operation.

[LoganBarnettASU]

Hi Manu,

I think I understand the motivation for the error, but why not let me merge at that point? My current option seems to be to copy the offending changes to another file, revert, update, then apply those changes back by hand without any intelligent or automatic merging. Is there a better way to get my changes from #500 in?

-Logan

[manu]

There's no way. You have to save your content. Update your work-space with the right revision, apply the changes and commit.

I'm wondering if the shelve will do the work. Not sure.

[LoganBarnettASU]

Just for everyone's info, shelving/applying has worked in the past, but we did something where even a shelve/apply wouldn't work.

Manu,

Is it possible we can get a merge option one day? I trust your tool to handle automatic merging far better than myself (: even moreso when less technical members of the team need to merge text based assets.

[manu]

Can you elaborate a little bit more the merge option you want?

[LoganBarnettASU]

When the parents don't match (using your example with #500 and #555), allow me to merge #500 with #555. The dream is that Plastic would walk back and see that #500 and #555 share a common ancestor (let's call it #499) and thus have a basis for merging and knowing what can be auto-merged vs. manual conflict resolution.

Does that seem reasonable?

Thanks for working with me on this! (:

[cidico]

I've got this error before and never understood what was wrong...

Thanks Manu!

By the way, how can I change a file and change my workspace?

I think that Plastic should not allow an switch workspace operation without checking in, shelving or undoing the changes, instead of an error message like this...

I think it's a bit confusing because in this case, I already "changed context" and the past changes still there...

[manu]

It sounds good, but I think it's a little bit hard to implement. I'll speak with the team.

On the other hand I guess that this situation is not very common right? You have to be careful when you are switching between branches, you have to keep your workspace clean.

[manu]

Cidico you are actually able to deny the operation by enabling it in the options.

Take a look into the first group of preferences inside "Other options"

[cidico]

Huuuuuuuuuuuuuuuuummmmmmmmm

Plastic SCM: Always ahead of the time...

Thanks Manu!

[LoganBarnettASU]

It sounds good, but I think it's a little bit hard to implement. I'll speak with the team.

On the other hand I guess that this situation is not very common right? You have to be careful when you are switching between branches, you have to keep your workspace clean.

I really appreciate that!

I'd say we hit this problem a few times a week. Some users get it more than others. We rarely make branches (we're just not in the habit of it yet). We do often use the branch explorer to update (switch workspace to this changeset), rather than the through the items view. That's because we've found that sometimes update doesn't follow across a merge (I'm not entirely sure there, I haven't done a ton of testing on it).

[manu]

Ok, in that case I do recommend you to enable the setting I told Cidico. This will prevent this kind of situations.

[carpediemevive]

I keep that option checked all the time. It's a pain when it happens, but the alternative is much worse. Typically I open up pending changes and either shelve it all or revert it all. A few extra seconds but worth it.

[manu]

Yes, but keep in mind that allowing the commit in that situation is quite dangerous... We can add my mistake regressions since you are removing the changes between your changed revision and the on you should be loading...

So that's why we alert the user if we find this situation. It's not a SCM error it's more like a live safe reminder.