Jump to content


Identifying an integrated change that was backed out


  • Please log in to reply
4 replies to this topic

#1 arash

arash

    Newbie

  • Members
  • Pip
  • 8 posts

Posted 04 May 2013 - 12:18 AM

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

#2 Mailman Sync

Mailman Sync

    Advanced Member

  • Maillist Aggregator
  • 2495 posts

Posted 04 May 2013 - 01:35 AM

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


> 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@perforce.com [mailto:perforce-user-bounces@perforce.com] On Behalf Of arash
Sent: Friday, May 03, 2013 8:20 PM
To: perforce-user@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.perfor...-was-backed-out
_______________________________________________
perforce-user mailing list  -  perforce-user@perforce.com http://maillist.perf...o/perforce-user
_______________________________________________
perforce-user mailing list  -  perforce-user@perforce.com
http://maillist.perf...o/perforce-user


#3 Gabor Maghera

Gabor Maghera

    Advanced Member

  • Sandbox Beta
  • PipPipPip
  • 192 posts
  • LocationElk Grove, CA

Posted 04 May 2013 - 02:00 AM

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@mathworks.com> wrote:

Quote

Quote

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@perforce.com [mailto:perforce-user-bounces@perforce.com] On Behalf Of arash
Sent: Friday, May 03, 2013 8:20 PM
To: perforce-user@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.perfor...-was-backed-out
_______________________________________________
perforce-user mailing list  -  perforce-user@perforce.com http://maillist.perf...o/perforce-user
_______________________________________________
perforce-user mailing list  -  perforce-user@perforce.com
http://maillist.perf...o/perforce-user
_______________________________________________
perforce-user mailing list  -  perforce-user@perforce.com
http://maillist.perf...o/perforce-user



--
Gabor

#4 P4Sam

P4Sam

    Advanced Member

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

Posted 04 May 2013 - 03:51 AM

With the newest (engine=3) version of integrate you can do this by copying from an old rev (i.e. a point on another branch which does not contain the change you want to get rid of).  Here's an example:

Posted Image

In this scenario, main#2 has been integrated into dev#1, and then later we decided that we want to roll dev back to main#1, so we've forced a copy from that revision.

Observe that with the old engine (-2), main#2 is still considered to be integrated (because it was integrated at some point in the past), but with the new engine (-3), we recognize that the change has been rolled back and is therefore once again a candidate for integration:

C:\test\local\client\j\rollback\ReBaseDev>p4 integ -2n main dev
main - all revision(s) already integrated.

C:\test\local\client\j\rollback\ReBaseDev>p4 integ -3n main dev
//depot/j/rollback/ReBaseDev/dev#3 - integrate from //depot/j/rollback/ReBaseDev/main#2

(With the old engine there are actually some cases where this will work, but only "by accident", so once upon a time there were cases of users making use of the "accidental" feature and then running into problems when they hit situations where the stars were no longer correctly aligned to have it work the way they wanted -- one of the many goals for development of the new engine was to support this type of usage intentionally and consistently.)

#5 Chuck O'Neill

Chuck O'Neill

    Member

  • Members
  • PipPip
  • 12 posts

Posted 06 May 2013 - 06:16 PM

Hi Arash - you've had some excellent replies on how to handle this, but I'd like to clarify that I don't regard it as a "corner case" that needs to be "covered."  When changes are merged from one branch to another in Perforce, the user can accept, reject or alter the change.  Once the user does that merge, then the user has resolved it and there is no reason to repeat the merger.  Normally the ability to "undo" an integration history is a mistake and should be approached with caution.
Hope that helps - Chuck




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users