CODEWITHSUNDEEP
perforce
Norbert Nemec
Norbert Nemec

Reputation: 73

How to identify/verify full integration points in the perforce history

In an analysis of the history in our perforce depot, I need to identify those changes where a full integration from another branch was performed and also find out the exact change number of the source of that integration. Unfortunately, even though such a full integration is a common operation, I could not find any easy and reliable way to detect it in the history. Please let me know if I missed something.

In any case: via a set of scripts using 'p4 filelog' and matching up revision numbers, I managed to find all candidate changes and their respective integration source change. What I am missing is a means to distinguish full integrations from cherry-picks or partial integrations limited to a subdirectory. For this, the closest I could find is the 'p4 interchanges' command, which does exactly the thing I need, except for the problem that the 'toFile' argument cannot have an '@' revision specification.

I would have hoped that

p4 interchanges //depot/sourcebranch@123400 //depot/targetbranch@123499

would tell me whether any changes were missing in the integration point I found, but it only gives the error 'A revision specification (# or @) cannot be used here.' - which matches the documentation.

Is there any other means to examine integration points in the p4 history to distinguish cherry-picks from full merges?

Upvotes: 2

Views: 628

Answers (2)

Samwise
Samwise

Reputation: 71517

Use the undoc p4 integ -C changelist command:

p4 integrate -1 -2 -C changelist# -Rlou -Znnn
    ...  The -C
    changelist# flag considers only integration history from changelists
    at or below the given number, allowing you to ignore credit from
    subsequent integrations.  ...

Hence:

p4 integ -n -C 123499 //depot/sourcebranch/...@123400 //depot/targetbranch/...

should tell you whether sourcebranch@123400 was fully integrated into targetbranch@123499. If you use -C 123498 in theory the difference in the output will show you which files were integrated.

There are probably some edge cases around deleted files -- e.g. if you integrate a deleted file into a file that's deleted at the head revision, it will report "up to date" regardless of integration history, so I can imagine that a file that was skipped for that reason but then subsequently re-added might give a false positive with the above method. (Or it might not -- I have vague memories of possibly fixing that scenario, but undoc bug fixes don't show up in the relnotes...)

Here's an example where foo@2 was integrated into bar@3:

sams-mbp:test samwise$ p4 filelog ...
//stream/main/test/bar
... #2 change 4 delete on 2019/07/21 by samwise@samwise-dvcs-1517552832 (text) 'delete'
... #1 change 3 branch on 2019/07/21 by samwise@samwise-dvcs-1517552832 (text) 'branch'
... ... branch from //stream/main/test/foo#1
//stream/main/test/foo
... #2 change 6 edit on 2019/07/21 by samwise@samwise-dvcs-1517552832 (text) 'edit'
... #1 change 2 add on 2019/07/21 by samwise@samwise-dvcs-1517552832 (text) 'add'
... ... branch into //stream/main/test/bar#1


sams-mbp:test samwise$ p4 integ -n -C 2 foo@2 bar
//stream/main/test/bar#2 - branch/sync from //stream/main/test/foo#1
sams-mbp:test samwise$ p4 integ -n -C 3 foo@2 bar
foo@2 - all revision(s) already integrated.

With -C 2 (before the branch), we see a replay of the integration as it would have happened as of that point in time. With -C 3 (the changelist of the branch), we see "all revisions integrated" because by that point in time it had already happened.

Upvotes: 1

Norbert Nemec
Norbert Nemec

Reputation: 73

After continuing to try out all combinations of arguments, I finally found a solution that works for me:

p4 interchanges -b SOURCE_to_TARGET //depot/targetbranch/...@targetchange

will print out all changes on the source branch that are missing on targetbranch@targetchange. It will return only changes older than targetchange. If this list contains no changes older than sourcechange, the targetchange was a full integration.

The command may take considerable time to complete when the returned list is long. Unfortunately, I can't find a way to truncate this search, but I can live with that.

As it seems, some of this functionality was buggy up to server version 2018.2 which might have caused difficulties in my earlier attempts.

Upvotes: 0

Related Questions