Jump to content


Unresolvable conflicts when merging changes down to a stream.

stream merge conflict

  • Please log in to reply
4 replies to this topic

#1 brockheinz

brockheinz

    Member

  • Members
  • PipPip
  • 11 posts

Posted 20 August 2015 - 10:33 PM

We have a stream that was set up a few months ago, and then went unused. Yesterday, I tried to get it up to date with it's parent, but ran in to some odd problems. Certain files will come up as having conflicts (even though no changes have been made in the child stream), and there is no way to resolve them. If I open up the "Reolve Files" window and choose "Accept Source", the file will drop out of the Resolve Files window as if the command has gone through. However, the file will still be listed as having a conflict when I view it in the changelist, and I won't be able to commit the changelist.  
It seems to help if I integrate smaller numbers of changes at a time, but this is very time consuming. It doesn't seem like this should be an issue, since there are no changes to the target files. Any idea what we can do to make these merges go through cleanly?

#2 P4Sam

P4Sam

    Advanced Member

  • Members
  • PipPipPip
  • 484 posts
  • LocationSan Francisco, CA

Posted 21 August 2015 - 04:39 AM

1) Do you have the same problem if you run "p4 resolve -at" from the command line rather than "Accept Source" in P4V?
2) What version of P4V are you using?

#3 brockheinz

brockheinz

    Member

  • Members
  • PipPip
  • 11 posts

Posted 25 August 2015 - 08:32 PM

Sam, thanks for your help. With "p4 resolve", it still won't accept the incoming changes, but it does give more useful output. Some of the files give one of these two errors:
"can't move to an existing file"
"can't delete moved file; must undo move first"

I am using P4V version NTX64/2014.3/1007540

#4 brockheinz

brockheinz

    Member

  • Members
  • PipPip
  • 11 posts

Posted 26 August 2015 - 01:40 AM

Since we have a few streams in this state, I'd like to "nuke them from orbit" and set them up properly. What would be the correct way to do that? Delete the stream, then obliterate the branch?

#5 P4Sam

P4Sam

    Advanced Member

  • Members
  • PipPipPip
  • 484 posts
  • LocationSan Francisco, CA

Posted 26 August 2015 - 05:20 AM

What's happening is that you've got a sequence of changes in the source stream that won't "squish" nicely into a single changelist in the target -- files have been moved multiple times, other files have been recreated in the spot where the files were moved to, and a single changelist can't contain the entire sequence of revisions that represents all of those changes in state.  This ends up manifesting as errors during "p4 resolve" where resolving one set of source changes requires putting a file in a spot where it can't fit, or opening a file for delete that simultaneously wants to be opened for add, or something like that.

So one option is to just forget about trying to represent all those changes and blast the target -- you could do that by deleting it and by branching over it, or you could just "p4 copy" over it (ignoring the warnings it'll give you about creating messy history) and that'll most likely work out okay too (although if you have a lot of tricky things going on I'm hesitant to give any blanket guarantees).

Another option is to "p4 copy" over it and NOT ignore the warnings it'll give you -- at the end of the warnings there ought to be a suggestion of an earlier change you could try copying from (this is derived by looking at the moved files that seemed to have problems and then backing up to the changelist corresponding to the oldest move).  This is essentially what you were doing with integrating smaller sets of changes, except "p4 copy" will hopefully take the guesswork out of it -- do a "p4 copy -n", check the warning, then "p4 copy @change" as suggested (hopefully the suggestion will have been a good one and this will go through cleanly), then repeat until there are no more warnings.  With the "hints" provided by the server it's much less time consuming and you could in theory script the whole thing.  By the end everything will be nicely in sync with all of the history matching up in both places.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users