Jump to content


obliterate and streams


  • Please log in to reply
5 replies to this topic

#1 j.mueller_rfg

j.mueller_rfg

    Newbie

  • Members
  • Pip
  • 2 posts

Posted 12 February 2019 - 04:46 PM

Hi folks,

I'm currently working on a script to remove older revisions of certain file type from our repository by obliterating them. The required criteria is that the revision is not the head revision and older than a specified threshold. So far everything works as desired.
But when it comes to working with streams I'm in need of some clarification on the following scenario:

Stream B is derived from A when file revision 3 is current and than after branching revisions 4 and 5 are checked in into A while B remains untouched. So when now, after some time, I would now run my script on stream A it would identify the files revision 3 as outdated while this is still the head revision in Stream B. If I now obliterate the file:3 in steam A would this also erase the current and still required head revision in B?

Thanks in advance for any advice on this topic.

#2 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 784 posts

Posted 19 February 2019 - 03:27 PM

No, B will remain untouched.  However, you will erase the common base between A and B, so the next time you merge it will be baseless (all changes will conflict, and if you aren't careful you might lose the newer ones).

#3 j.mueller_rfg

j.mueller_rfg

    Newbie

  • Members
  • Pip
  • 2 posts

Posted 21 February 2019 - 04:35 PM

Hi Sambwise,
thank you very much for your explanation. This is in fact the answer I was hoping for and merging can and will not be an issue with these files anyway.

#4 Matt Janulewicz

Matt Janulewicz

    Advanced Member

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

Posted 10 April 2019 - 12:30 AM

I realize it's been two months, but if you haven't done this yet I'd recommend not doing it. You're obliterating revisions that might not seem important now but may be in the future for various reasons (acquisition, a bug that needs fixing, etc.), plus you are making it awkward for future Perforce administrators when they come across missing revisions. I speak from experience, the the point where I pretty much only use obliterate when one of two things happen:

1) Someone checks in a password or other security-related info they shouldn't have, or
2) A newbie branches a million files (in that case it's easy to see that all revision #1's need to go.)

Never use obliterate because it seems like a convenient solution to a problem. There are future ramifications of obliterate that are sometimes well beyond the human capacity to foresee them.
-Matt Janulewicz
Staff SCM Engineer, Perforce Administrator
Dolby Laboratories, Inc.
1275 Market St.
San Francisco, CA 94103, USA
majanu@dolby.com

#5 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 784 posts

Posted 10 April 2019 - 07:32 PM

I realize seeing this topic bumped that I missed a chance to plug "p4 obliterate -i/-I", which is a fun little hack around the problem of obliterating a common ancestor:

p4 obliterate [ -iI ]
	 Tells obliterate to synthesize new integration records to attempt
	 to bridge the gaps left by the obliteration of intermediate branches.
	 If '-i' is used, only the initial branch records are considered; if
	 '-I' is used, all records are considered. Note that it is possible
	 to end up with more integration records than you started with.

The "ending up with more than you started with" scenario is where you obliterate a mainline, and all of the N siblings now have to be connected to each other N squared ways...  :blink:

#6 Matt Janulewicz

Matt Janulewicz

    Advanced Member

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

Posted 17 April 2019 - 11:04 PM

I'm still going to maintain my healthy paranoia around obliterate. I think most p4 admins have a horror story about a slip of a finger that just about cost them their jobs/careers, that decades later they wake up in a cold sweat about. :)
-Matt Janulewicz
Staff SCM Engineer, Perforce Administrator
Dolby Laboratories, Inc.
1275 Market St.
San Francisco, CA 94103, USA
majanu@dolby.com




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users