Jump to content


P4 Undo, P4 Rollback, P4 Backout

revert rollback backout undo

  • Please log in to reply
2 replies to this topic

#1 vumi

vumi

    Newbie

  • Members
  • Pip
  • 2 posts

Posted 03 April 2017 - 04:36 PM

Hello guys,

I've seen that in 2016.2 server "p4 undo" was introduced - I wanted to know how different it is from rollback/backout?

Documentation is pretty vague and I couldn't find any good real life examples (since I can't use 2016.2 right now and I am looking into profits of an upgrade).

After this operation - will perforce server notice that already integrated revisions (by undone changelist X) were undone and are needed to be integrated again?

#2 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 232 posts

Posted 03 April 2017 - 10:21 PM

First, note that since "p4 undo" takes a rev range you can use it for either rollback or backout.  Rollback is "p4 undo @start,@now", backout is "p4 undo @only,only", and you can do anything in between, like "p4 undo @start,@finish", or even the perverse "p4 undo #1,#head" (which just deletes everything, i.e. a rollback to rev #0).

The "p4 undo" command is a server-side implementation of rollback/backout that was designed to be both faster and correcter than the rollback/backout features in P4V.  Usually features like this have accompanying blog posts that describe them in some detail with examples; if I were a betting man I would bet that there is one of those posts already written up for "p4 undo" that's just waiting to be published, and I imagine it would be very helpful to you if you could convince someone at Perforce to publish it.

But, going off memory, one of the big differences (worth the price of admission on its own) is that it handles "move from" revs correctly -- whereas P4V's "back out" will sometimes see a "move/add+move/delete" and back it out as "delete+add", "p4 undo" is pretty strict about maintaining parity.  If you move A to B and B to C, and then you roll back that entire range of changes, the "undo" will even be transitively clever and record it as a move from C to A.

As far as undone integrations, that's a bit more of an advanced feature, but it's in there.  Another benefit of the native "p4 undo" command is that it records more descriptive integration records, i.e. "undone", which provides a useful trail in the metadata to let you know what revisions got undone, and having this information in the metadata means that the integration engine can make use of it.  Again, this would be the sort of deep-divey technical detail that would normally be described in something like a blog post that may well have already been authored.  If memory serves, there's an undoc configurable (prefixed with dm.integ, I forget whether it was "mergeundone" or something like that, but check "p4 help undoc" on a 2016.2 server and it ought to be in there) that will enable exactly that behavior when you turn it on.  The default (i.e. if you don't turn that undoc configurable on) is for the integration engine to just ignore the "undone" records so the behavior is more like what you're used to with an "old fashioned" rollback.

#3 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 232 posts

Posted 05 April 2017 - 03:51 PM

View PostSambwise, on 03 April 2017 - 10:21 PM, said:

If memory serves, there's an undoc configurable (prefixed with dm.integ, I forget whether it was "mergeundone" or something like that, but check "p4 help undoc" on a 2016.2 server and it ought to be in there) that will enable exactly that behavior when you turn it on.  The default (i.e. if you don't turn that undoc configurable on) is for the integration engine to just ignore the "undone" records so the behavior is more like what you're used to with an "old fashioned" rollback.

Here it is:

	dm.integ.undo			0 Enable re-integration of undone changes






Also tagged with one or more of these keywords: revert, rollback, backout, undo

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users