CODEWITHSUNDEEP
mergeperforce
infojolt
infojolt

Reputation: 5418

How does Perforce deal with changes made after merge/integrate, but before submit?

I have seen behaviour in Perforce that I am unable to explain. I took a branch of the trunk and worked on this regularly committing my changes and occasionally merging from the trunk to my branch to ensure there were not going to major conflicts when I reintegrated.

When this work was complete, I used the Perforce Merge/Integrate option to apply the changes to the trunk. After sending these changes for code review, I made some changes on the trunk. At this point, none of the changes had been committed to the trunk.

When I went to commit all of these changes, the diff showed the files exactly as I would expect. After submitting the changelist, the changes which were submitted were not the same as what was shown in the diff window. Instead, the changes that I'd made since the Merge/Integrate were not there. Doing a diff between the server and my local copy on the trunk had all of the changes to the same files made after the code review. As such, I had to do a second commit to mend the broken build.

I'm confused how this happened as I thought Perforce only kept one local copy of each file on the client?

Even if there is a flag showing the files have been tampered, where were the files it submitted? It definitely showed the trunk paths in the commit window, but I guess it could have got the files from the branch?

Another question would be, how should I have best dealt with the above scenario when using Perforce version control?

Upvotes: 0

Views: 2077

Answers (2)

Bryan Pendleton
Bryan Pendleton

Reputation: 16359

One mistake we've all made is to (a) integrate a file from one branch to another, (b) resolve it as "accept merged", (c) make local changes to the file prior to (d) submit. If you don't explicitly open the file for edit after step (b) and before step (c), the server has no knowledge of your local changes.

Upvotes: 5

Jeff Watkins
Jeff Watkins

Reputation: 6359

You made your first mistake editing things directly on your copy of trunk. Always use a task branch. It probably didn't cause the issue you were seeing, but if you'd messed up your task branch it wouldn't have broken the build. When looking at your local copy of trunk, ensure you've refreshed it from the depot. You'll get little yellow triangles if your local copy of a trunk file is out of date, editing and committing an out of date file on your copy of trunk is bound to lead to "odd" behaviour.

I'm confused how this happened as I thought Perforce only kept one local copy of each file on the client?

One copy for trunk, one copy for each task branch.

Upvotes: 0

Related Questions