Jump to content

Is it possible to branch a deleted revision at tip?

integration branching

  • Please log in to reply
3 replies to this topic

#1 Bruce Mc

Bruce Mc

    Advanced Member

  • Members
  • PipPipPip
  • 84 posts
  • LocationSeattle Area

Posted 03 December 2015 - 01:51 AM

Recently we spun up a feature branch from our trunk. As part of this work, we started taking vendor drops into a storage location in our archive and integrated these drops into our feature branch.

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?



#2 P4Sam


    Advanced Member

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

Posted 03 December 2015 - 02:31 AM

The "-f" flag on "p4 populate" and "p4 copy" will let you create a branch that contains all of the deleted revisions from its parent, in order to handle cases like this.  I'm not a big fan of that approach as a general rule because every new branch you create ends up getting bloated with an increasing number of deleted revisions, and the vast majority of the time it's fine to just forget about those files as you go forward.  It's also a little hard to make that work when you need to do it as part of a merge rather than actually creating an entire new branch.

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.)

#3 Bruce Mc

Bruce Mc

    Advanced Member

  • Members
  • PipPipPip
  • 84 posts
  • LocationSeattle Area

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.



#4 Mailman Sync

Mailman Sync

    Advanced Member

  • Maillist Aggregator
  • 2495 posts

Posted 03 December 2015 - 08:15 PM

Originally posted to the perforce-user mailing list by: Michael Mirman

Hi Bruce -


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.

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. ;-)

Michael Mirman
MathWorks, Inc.
3 Apple Hill Drive, Natick, MA 01760

perforce-user mailing list  -  perforce-user@perforce.com

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