5

I am using the Perforce P4V client (version 2013.1/611291, dated 2013 March 20).

I attempted to Merge/Integrate from the main branch to my feature branch. It had been a long time since I had done this, so a significant number of files were added to the changelist. I then resolved conflicting files that could not be merged automatically. I then submitted the changelist. After doing that, I discovered that some of the files had remained in a messy conflicting state. Exactly why is a mystery to me, but instead of trying to fix them, I thought it would be easier to just undo the Merge/Integrate entirely and start over again.

To undo the Merge/Integrate, I used the 'back out' option. All affected files were added to the 'back out' changelist and I submitted it. My feature branch is now back where it was to start with, except obviously by now all affected files have had their revision number bumped up twice, and the history for affected files shows the integration and then the subsequent 'back out'.

The problem is that if I try the Merge/Integrate option again, this time round the number of files that Perforce wants to put into the integration changelist is now a fraction of those it originally tried to integrate. Put another way, it's not adding lots of files that I know are most definitely further forward in terms of development in the main branch.

The only way I seem to be able to get around this is to use the advanced option Force integration on all revisions, disregarding revision history (-f). With this option set, it will then add for merge all files from the branch.

I suspect the problem is something to do with the fact that the files now have an integration marked in their history, and therefore Perforce is using that point as the base. The fact that the messed-up integration was 'backed out' doesn't make any difference to that.

I tried to do a rollback as well, but the same problem remains.

How can I solve this?

Edit I have later realised that there is the following similar question: How can I undo an Integration in Perforce, and still be able to redo it?

Community
  • 1
  • 1
Trevor
  • 10,903
  • 5
  • 61
  • 84

1 Answers1

5
  • The files which you're trying to integrate from the main branch to your feature branch have an integration history after your first integration check-in.
  • When you backed out the changes, you got your feature branch's files to the state where it was before the integration, but new versions of the files were created for each of the file in that previous changelist.
  • The next integrate hence tries to bring in ONLY the difference in the integration path since last time.

As you've mentioned already, the only way out of this situation is to run a force integrate using the -i. You can still resolve the changes using p4 resolve -as ... and p4 resolve -am ... just like last time, and then hand resolve the remaining conflicts to perform the merge. Except that the history would show 2 extra versions of the files changed in the prior merge commit and the commit for backing it out.

  • If you're okay with creating a feature branch at a different location and discarding the one at your current location, you could set the starting point for the new feature branch to be the commit/changelist just before you performed the problematic integrate.
  • Integrate from your main branch into the new feature branch and you should have a much cleaner history this time and should have all the file changes (with history) you've made in your original feature branch as well.

Unlike other version control systems (like git for example), it is unfortunately not possible to rewrite history in perforce to make it forget about the integration history and start fresh again.

This is one of the reasons in my company, all the architects and SCMs are very much picky and reiterating their workflow advice, about strictly following integration paths between branches when performing integrations using perforce.

Tuxdude
  • 47,485
  • 15
  • 109
  • 110
  • Many thanks indeed for your answer - it's really greatly appreciated. Time for me to hit the sack now actually (my poor head has had enough!) so I'll come back to this tomorrow and properly run though your recommendations. At an initial glance though it does seem that you're confirming that I originally suspected, which is that a 'nuke from space' option could be the only resolution here. I use Perforce at work but for personal purposes I use `git` heavily, which seems to be more forgiving in these kind of situations as you say. – Trevor Apr 30 '13 at 22:54
  • 1
    Strictly speaking, there *are* ways to rewrite history in Perforce and make it forget about the integration history and start fresh again. But they are very advanced and subtle, and you should only undertake them if you are desperate, and then only with the help of Perforce Technical Support. Otherwise, follow Tuxdude's excellent advice. – Bryan Pendleton May 01 '13 at 02:15
  • 1
    @BryanPendleton - I believe you're talking about `p4 obliterate` as described [here](http://answers.perforce.com/articles/KB_Article/How-To-Rollback-An-Integration). I did not mention it for the very same reasons you pointed out :) First of all, it requires escalated privileges (superuser) in perforce, and next `obliterate` is a dangerous command to be run for removing versions of file from the perforce database. @Trevor, as Bryan pointed out, if you wish to use `p4 obliterate`, please do take a SCM Admin's help before proceeding. – Tuxdude May 01 '13 at 03:47
  • @Tuxdude Thanks again. Just to give an update, what I am finding is that when I try the `-i` option, a subsequent auto merge (`-am`) results in 100s of files that cannot be auto merged and so require hand merge. The reason seems to be that revision #1 is always being used as the common base (which makes sense due to `-i`), meaning if both source and target contain a same change that was performed since #1, it's marked as a conflict, when normally it wouldn't be. Therefore, unless I've missed a trick here, I think it's either a matter of lots of hand work, or go for the clean branch option. – Trevor May 07 '13 at 09:16
  • p4 obliterate wasn't created to do this sort of thing. It was actually created at the request of a large open source project, so they could entirely remove contributions that turned out to have licensing/ownership problems. obliterate is a very crude tool, and should probably not be considered part of any 'normal' Perforce workflow. – Wexxor Aug 07 '14 at 18:54