[p4] Identifying an integrated change that was backed out

Gabor Maghera gmaghera at gmail.com
Fri May 3 18:55:47 PDT 2013


If you want to deal with the situation without using obliterate, you can try this workaround.  Let's consider change A in codeline SOURCE, which was integrated to codeline TARGET in change B, and you need B backed out.  


1. Back out A in SOURCE - this will be change C
2. Integrate C from SOURCE to TARGET (at this point you've achieved the backout sought after)
3.  Back out C in SOURCE.  (You do this to restore the contents of change A in such a way that it shows up as a candidate for integration from SOURCE to TARGET, when you're ready)


Cheers,
Gabor
—
Sent from Mailbox for iPhone

On Fri, May 3, 2013 at 6:35 PM, Michael Mirman
<Michael.Mirman at mathworks.com> wrote:

>> I'm wondering if anyone has any smart way of covering this corner case, so we can have the Merge Report report that the backed out change needs to be merged.
> We had a case like this recently.
> The only thing I know of to "fix" the integration history is to obliterate the revisions, which are the result of those integrations. :-(
> --Michael Mirman
> MathWorks, Inc.
> 3 Apple Hill Drive, Natick, MA 01760
> 508-647-7555
> -----Original Message-----
> From: perforce-user-bounces at perforce.com [mailto:perforce-user-bounces at perforce.com] On Behalf Of arash
> Sent: Friday, May 03, 2013 8:20 PM
> To: perforce-user at perforce.com
> Subject: [p4] Identifying an integrated change that was backed out
> Posted on behalf of forum user 'arash'.
> I have a corner case regarding Perforce integration history that is impacting our Merge Report tool's results.
> The Merge Report is a tool we have that runs "p4 interchanges branch1 branch2" to identify changes that were checked into branch1 and need to be merged into branch2, and notifies the submitter that the change needs to be merged to branch2.
> The situation is :
> - User checks Changelist 10000 into branch1
> - Merge Report identifies Changelist 10000 as needing to be merged into branch2, and notifies User
> - User merges Changelist 10000 from branch1 to branch2. This happened as Changelist 10001
> - User does testing and realizes branch2 is not ready for this change, and backs out Changelist 10001 from branch2. This happens as Changelist 10002
> So as a result the contents of Changelist 10000 are no longer in branch2
> When the Merge Reports runs again, it is no longer identifying Change 10000 as needing to be merged into branch2.
> I'm guessing Perforce doesn't UNDO the integration history for Change 10000, just because the change was later backed out.
> I'm wondering if anyone has any smart way of covering this corner case, so we can have the Merge Report report that the backed out change needs to be merged.
> Thanks,
> Arash
> --
> Please click here to see the post in its original format:
>   http://forums.perforce.com/index.php?/topic/2525-identifying-an-integrated-change-that-was-backed-out
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com http://maillist.perforce.com/mailman/listinfo/perforce-user
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user


More information about the perforce-user mailing list