# Why do some files get reported as ignored by "p4 resolved" during integration

p4 integrated

7 replies to this topic

### #1 engr.vns

engr.vns

• Members
• 43 posts

Posted 30 May 2020 - 07:01 AM

Assume that a user has integrated files from project1 to project2 as -

STEP 1: p4 integrate //project1/... //project2/...
STEP 2; p4 resolve -as

The user than verifies the integrations that are ready for submission in project2 as -
p4 resolved //project2/....

This report lists some of the files as being  ignored -
//project2/file1 - ignored //project1#3,#4

Why are files being reported as ignored when there the user is not excluding any files.
If you diff these files between project1 and project2 they are indeed different.

There are no errors in the integration process.

### #2 Sambwise

Sambwise

• Members
• 1192 posts

Posted 30 May 2020 - 02:39 PM

"Ignored" means that the revisions that you integrated (i.e. the ones on the project1 side) were ignored.  If you did the resolve with -as this means that the contents of those revisions were redundant -- maybe the revisions were "empty" (i.e. no change) or maybe those changes were already in project2 (e.g. they had already been propagated between the two branches via some path that didn't confer integration credit).

Since an "ignore" causes the target file to ignore the source file, it's expected that diffing the target and source afterwards would show a difference (contrast to a "copy", where the target becomes a copy of the source).  The diff that would be more instructive would be to diff the source revision range:

p4 diff2 project1/file#2 project1/file#4

(given a source revision range of project1/file#3,#4 as in your example)

Or, better yet, diff project1/file#4 against the exact base revision, which you can get by adding the "-o" flag to the "p4 resolved" command.  (The base revision is probably in fact project1/file#2, but not necessarily, depending on the history of the two files.)

Whatever diff you see there was the "theirs" leg of the diff in the resolve.  Diffing the base against project2/file will show you the "yours" leg of the diff.  What you should find is that the "theirs" leg was a subset of the "yours" leg, i.e. it was either empty or it only contained lines that were already present in the target.

All of that is pretty straightforward and is more or less guaranteed to be true just based on the way that resolve -as works; p4 resolve in and of itself is a very simple beast and always comes down to the same calculation of "base vs theirs vs yours".

Further contextual questions may present themselves based on what you find in the diffs, e.g. "why were these diffs already in the target?", "why were these empty revisions created?", "why did that base get selected?", etc.    The answers to those root-cause questions (assuming you care that much) will lie in your file history and may require deeper investigation using p4 annotate, p4 filelog, etc.

### #3 engr.vns

engr.vns

• Members
• 43 posts

Posted 01 June 2020 - 05:57 AM

But the issue remains these files should NOT have been ignored...

Assume PROJECT1 is donor project and PROJECT2 is receiver.
Here's the debug I did -
0) p4 revert PROJECT2/file1 //Revert all changes and just afresh
1) p4 integ -f PROJECT1/file1 PROJECT2/file1 //force integration to be safe
2) p4 resolve -at //-at accept whatever's incoming, PROJECT2/file should get overwritten from do not project
3) p4 resolved -o PROJECT2/file1
PROJECT2/file1 - ignored PROJECT1/file#1,#3 <- Notice ignored

One possibility for file1 to get ignored is there are no differences.

But if I do Either of
p4 diff2 PROJECT2/file1 PROJECT1/file#1 differences exist
p4 diff2 PROJECT2/file1 PROJECT1/file#3 differences exist

Which means lack of differences is not the cause of the ignore..

p4 filelog PROJECT2/file1 shows it has just one version which was integrated from PROJECT0/file1 (Notice PROJECT0)

What else could be the issue here...?

Thanks again

### #4 Sambwise

Sambwise

• Members
• 1192 posts

Posted 01 June 2020 - 07:09 AM

Could you re-do all of that and copy+paste the complete command line transcript?  It doesn't make sense that you'd see an "ignored" after doing a "resolve -at", unless something unusual was going on that would hopefully be reflected in some of the command output.

Note that if you do "integ -f", "resolve -as" and "resolve -am" are no longer trustworthy (you can easily lose changes if you do "integ -f" followed by any sort of automerge, since "-f" disables all the base selection smarts) -- but since you're doing a "resolve -at" you should generally get a "copy" regardless.  The only exception would be if the copy was overridden by some other resolve action (which, again, would show up in the output -- you might see additional information during "resolve", or multiple "resolved" records).

The fact that you felt the need to force the integration "to be safe" also suggests that something is missing from the narrative here -- maybe the changes were already merged?  Under the situation you described, there would be no need to "force" the integration.

### #5 Sambwise

Sambwise

• Members
• 1192 posts

Posted 01 June 2020 - 09:09 PM

This is one of the rare examples I can think of where a "resolve -at" would get you an "ignored" record:

C:\Perforce\test\delete>p4 resolve -at
c:\Perforce\test\delete\bar - vs //stream/main/delete/foo#1,#2
c:\Perforce\test\delete\bar - resolving delete from //stream/main/delete/foo#2,#3
//Samwise-dvcs-1509687817/delete/bar - ignored //stream/main/delete/foo
//Samwise-dvcs-1509687817/delete/bar - delete from //stream/main/delete/foo

C:\Perforce\test\delete>p4 resolved
c:\Perforce\test\delete\bar - ignored //stream/main/delete/foo#1,#2
c:\Perforce\test\delete\bar - delete from //stream/main/delete/foo#2,#3
c:\Perforce\test\delete\bar - resolved delete from //stream/main/delete/foo#2,#3

As far as I can think of, though, this would only ever happen in a case where there were multiple resolves, and one completely overrides the other (e.g. it's not possible for a file to simultaneously be a delete and be a copy of a non-deleted revision, so if one is accepted then the other is retroactively ignored).  I can't think of a way for it to happen with a simple one-to-one integrate.

### #6 engr.vns

engr.vns

• Members
• 43 posts

Posted 03 June 2020 - 05:15 AM

Hi Sambwise...
That's exactly what's happening...

- V

### #7 engr.vns

engr.vns

• Members
• 43 posts

Posted 03 June 2020 - 05:20 AM

Clarification to tie any loose ends here -
Does the order of the inclusion and exclusion in the branch spec make a difference on integration...

branch spec1:

branch spec2:

The contents of both what's included and excluded is the same but the ordering is different.
Does this make a difference on integration?
How would p4 reconcile the order in case of complex situations...

### #8 Sambwise

Sambwise

• Members
• 1192 posts

Posted 03 June 2020 - 01:16 PM

engr.vns, on 03 June 2020 - 05:20 AM, said:

Clarification to tie any loose ends here -
Does the order of the inclusion and exclusion in the branch spec make a difference on integration...

branch spec1:

branch spec2:

The contents of both what's included and excluded is the same but the ordering is different.
Does this make a difference on integration?
How would p4 reconcile the order in case of complex situations...

Later lines override higher ones for any namespaces where they overlap.  In the case of branch2, the exclusion has no effect because it's entirely overridden by the line after it.  In branch1, dir2 is excluded from the mapping.

In all cases, any given path can only be mapped to one place (or noplace) by a particular branch view.  The last line that maps a particular path always takes precedence.  The mapping is bidirectional (reversible), so in cases where paths are mapped differently on different lines, this rule applies to both sides of the view equally (i.e. if a given mapping is overridden when you integrate" forwards", it's overridden when you integrate "backwards" as well).

#### 0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users