Posted 03 December 2015 - 01:51 AM
We had a small handful of files in these drops that we didn't want in our source tree so we deleted them in our feature branch. These files have not changed since the first drop we took.
We regularly integrated changes from trunk to our feature branch. A point was reached where we were ready to move our feature work from the feature branch back into trunk and continue the feature's development work in trunk. We integrated the latest changes in trunk to the feature branch and then integrated our feature branch work into trunk.
Since our work had moved to trunk, we integrated new vendor drops into trunk. Interestingly, those handful of files we had removed from our feature branch got integrated into trunk from our vendor drop storage location. We then tried an integration from our feature branch into trunk again and the deletes of the handful of files appeared as pending integrations. We took those pending integrations into trunk and things are happy again.
It does seem reasonable that if a file in our feature branch is deleted and that file had never existed in trunk then nothing about that file would be integrated into trunk. In this particular case, it would have been nice to branch the deleted revisions of those handful of files to trunk when we integrated the feature branch's work into trunk.
Is it possible to do such a thing? If it's possible, is it recommend or discouraged?
Posted 03 December 2015 - 02:31 AM
What if you were to exclude these files from the drops entirely, by excluding them from the client view and/or branch view you use for the drops? (Or, if you're using streams, just excluding them from the stream that represents the dropped code, which has the same effect.)
Posted 03 December 2015 - 07:11 PM
Thanks for the info on the "-f" flag for the "p4 populate" and "p4 copy" commands.
Since we haven't run into particular corner case before and only expect it to re-occur very rarely, it feels like it is more trouble than it is worth to chase after altering the workspace and branch views.
We use a manifest system for the build's output and do a compile and a manifest pass for each check-in. Files disappearing and/or appearing in the output unexpectedly will cause a manifest pass error. Being aware of this corner case and being able to catch it right away will be good enough for us.
My question is more about making sure the problem is understood and checking to see if there is other knowledge available that could be helpful.
Posted 03 December 2015 - 08:15 PM
Hi Bruce -
checking to see if there is other knowledge available that could be helpful.
Yes, we often (although not always) use the -f option in populate.
I just discussed the reasons with my colleague who is much closer to this.
Say, we have stream Aparent, and it has children Achild1 and Achild2.
We want to introduce Ainter at the same level, but our workflow will be (yes, weird):
Aparent will be merging down to Achild1 and Achild2, but when Achild1 or Achild2 are ready to "promote" their code back, they have to go via Ainter. (We never use copy, and it is always merge - regardless whether it is between siblings or from a child to the parent. Let me skip the reasons for this workflow.)
If we don't use -f when Ainter is populated, then any possible conflicts between the existing deletions in Aparent may cause the wrong merge result when we merge Achild -> Ainter.
It's probably not the only reason for the -f option, and it is often related to some workflow, not recommended by the Perforce documentation. ;-)
3 Apple Hill Drive, Natick, MA 01760
perforce-user mailing list - firstname.lastname@example.org
Also tagged with one or more of these keywords: integration, branching
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users