Jump to content
Plastic SCM forums are now in Unity. Click here to open the new forum ×

Automatic merge losing client side changes

burley1ASU

By burley1ASU
in Branching and merging

Recommended Posts

burley1ASU Newbie

burley1ASU

Posted
Posted

We've been having some trouble merging our files using the built in Plastic merge tool. My colleague and I are editing the same file, she has already checked in, leaving me a revision behind.

http://i.imgur.com/2J0yY.png

I've got a change to the same file on a different line.

http://i.imgur.com/7ghhU.png

So I merge the files using these merge options.

http://i.imgur.com/VBAxL.png

And when I check the result my local changes have been lost.

http://i.imgur.com/TR8Ed.png

It seems to be a bug, and we are worried about this happening with more complicated files since it doesn't give us much indication that the changes have been lost, and the local changes are lost entirely. Do you have any idea what is happening?

Link to comment
Share on other sites
manu Newbie

manu

Posted
Posted

Hi burley,

I think I'm missing something due to this is a very easy scenario.

Can I connect with you to review it? We can even recreate the merge scenario and see if there's something wrong.

The conflict was a "Both contributors conflict"?

Link to comment
Share on other sites
  • 4 months later...
JakubH Newbie

JakubH

Posted
Posted

I've just run into this too! (4.1.10.355)

I lost my changes even though I had set Manual conflict resolution and specifically Merge your changes with the source contributor's changes. That is really bad, it would make Plastic unusable for us!

It looks like merging with local changes doesn't work at all. :-(

Link to comment
Share on other sites
JakubH Newbie

JakubH

Posted
Posted

It is easy to reproduce:

- make file test.txt with text abc

- change it as one user to abx and check-in

- change it as a second user to ybc and try to check-in → merge is needed

I choose merging and click Process merge. But it says that all changes are already in destination and it overrides my local changes.

I suppose the problem is that it takes an old changeset as a destination:

post-1925-0-06967800-1350404562_thumb.png

Link to comment
Share on other sites
manu Newbie

manu

Posted
Posted

JakubH,

please, can you record a video or something similar? It's a very easy scenario, In that case the merge tool must appear since the same like has been changed from you current changeset and the one Plastic is mergering from.

And of course, there is no data loss, in the worst of the cases there's a wrong merge result.

I'll be happy to schedule with you an online meeting to review the issue.

Link to comment
Share on other sites
JakubH Newbie

JakubH

Posted
Posted

I've made a series of screenshots. And I've found out, that the wrong behavior occur only in case that I change just one (conflicting) line.

This is the first changeset made by me:

post-1925-0-55260600-1350409906_thumb.png

This is the second changeset (made by user autotools):

post-1925-0-57425700-1350409913_thumb.png

Meantime, I change the test file:

post-1925-0-66556600-1350409956_thumb.png

Checkin needs merge:

post-1925-0-52205200-1350409957_thumb.png

There is one conflicting file:

post-1925-0-58323800-1350409958_thumb.png

Check settings:

post-1925-0-52105600-1350409959_thumb.png

I click to Process all merges.

It has resolved automatically!

post-1925-0-60000800-1350409960_thumb.png

My local change (abc to ybc) is gone:

post-1925-0-01690100-1350409962_thumb.png

I do undo changes and try doing more changes:

post-1925-0-51740700-1350410530_thumb.png

Merging is working now:

post-1925-0-79308600-1350409964_thumb.png

post-1925-0-06090900-1350409968_thumb.png

I might have time for a gotomeeting tomorow, if it helps.

Link to comment
Share on other sites
manu Newbie

manu

Posted
Posted

Yep,

it's a thing regarding the communication between the merge tool and Plastic, if in you example instead of changing abc to ybc you change to ybcc the thing will work.

You are totally right with the scenario and we are going to fix it today. Thank you so much for reporting.

It's actually really really uncommon to see this issue with real data files.

Link to comment
Share on other sites
JakubH Newbie

JakubH

Posted
Posted

I see. I made this example to test it separately, but it happened to me in a non-artificial case.

It looked somewhat like this:

base:

next version: 1.0.123

my change:

next version:
2
.0.123

build server's change:

next version: 1.0.12
4

Result was:

next version: 1.0.12
4

Instead of (manual merge):

next version:
2
.0.12
4
Link to comment
Share on other sites
JakubH Newbie

JakubH

Posted
Posted

Thanks. It has been fixed... partially. When I try to checkin, it asked for a merge and then the merge is correct already.

But, when I use the View new changes button in Pending changes view, it resolves it as an update only (it ignores my local changes).

Btw, the issue tracker screenshot is quite interesting. I wonder what the user pain percentage is. :P

Link to comment
Share on other sites
JakubH Newbie

JakubH

Posted
Posted

I've tested it and it is better now.

A merge window is still claiming Changes only in source contributor and For 0 items, both source and destination contributors have changes. But when I click Process all merges (there is not an Update button only), a manual merge is invoked, which is correct.

So messages are still wrong, but behavior is ok now.

Btw, I suggest to omit a sentence User interaction might be required (manual merge), when there are 0 items with conflict. It is confusing!

Link to comment
Share on other sites
  • 5 months later...

Archived

This topic is now archived and is closed to further replies.

Go to topic listing
×
×
  • Create New...