Jump to content


Member Since 20 Feb 2019
Offline Last Active Apr 03 2019 09:29 AM

Posts I've Made

In Topic: Move and integrations

03 April 2019 - 09:30 AM

We don't use streams yet. In your blog you start with the old workaround of branch specs, then move over to using streams. So is this only possible with streams? I mean when 2 branches have different directory trees after one of them has moved stuff, and some magic branch spec is updated in the background in order to keep the files on different directories mapped when integrating between the 2 branches?

In Topic: Move and integrations

22 February 2019 - 11:07 AM

It was a real p4 move. Would that also work over several branch integrations or does this also require populate -f?

In Topic: P4 integration of deletions

22 February 2019 - 08:05 AM

View PostSambwise, on 21 February 2019 - 07:16 PM, said:

In theory, every time you create a branch there could be an exhaustive search of all branches of the source file to see if there was ever a deletion in a sibling branch, and then some sort of heuristic could be applied by looking at other files in the branch to "guess" whether the file should be propagated, but since each file has its own history it would indeed have to be a guess (and it would also increase the performance cost of branching by orders of magnitude).
The exhaustive search would not be required at branch creation but at integrate/resolve. And even then it would not require to search all branches, but only up to the common base. Here you say there is no common base because the file does not exist anymore. I would expect to search the whole branch integration history to find deletion. But as P4 seems to only work on file histories there is no history without the file anymore. The "branch" has no own history, only the single files.

Thanks for the workshop PDF, going to study that..

I think about making populate -f the default for next branches. As file count of branches is increasing, so will the deletion count increase at a lower level. But large moves and re-organization could lead to lot of deletions in the history. I guess a "p4 move" is still an integrate+delete as in the early days, true?

By the way, we had issues with move and integrations, which I'm filing as a new thread topic.

In Topic: P4 integration of deletions

21 February 2019 - 11:48 AM

Thank you very much. Indeed my description was wrong, corrected sentence is:


If you integrate old PROJECT_B, that has been created before the deletion, to PROJECT_C...

I understand now, that either every integration must be done with populate -f OR I need to integrate back to a line where the deletion is still "known". So without knowing that line the best would be anyway to always integrate back to the origin line where the branch was created from, and then to the next lines from there.

Questions about that populate -f: I never tried populate, is that like integrate + submit? That -f flag doesn't exist for integrate, only for populate. There is some other -f for integrate that means something else:


The -f flag forces integrate to ignore integration history and treat
all source revisions as unintegrated. It is meant to be used with
revRange to force reintegration of specific, previously integrated
The -f for populate means:


The -f flag forces deleted files to be branched into the target.
By default, deleted files are treated as nonexistent and simply
What is the drawback of using populate -f always? I see, there will be more and more deleted files to be kept, on every cleanup and re-sorting. But is that an issue? We hide those in P4V. I don't know much about the P4 internals, but why does every line store the deleted files? For integrations, the resolve could do that. It must find the common base anyway, and if one branch to that base has a deletion on the way and the other not, then the deletion is the result of the resolve, that's my view on that. Wrong?