[p4] How to *really* back out a revision
smith_roy at emc.com
Tue Mar 25 15:37:47 PDT 2008
We've got an ugly problem caused by an accidental submit to a release
Our patch generation process depends on file timestamps changing.
Skipping a few details, we build the baseline, then resync to the
head of the release branch, then rebuild. Anything that's changed,
gets put into the patch.
Somebody accidentally submitted a new version of a commonly used
header file to the release branch. There's lots to talk about how to
prevent that from happening again, but that's a different story, and
what's done is done. We can resubmit the correct version as the new
head revision. That will result in the correct source file
*contents* being on #head, but as far as make is concerned, when we
rebuild, the file timestamp will have changed. That will cause a lot
of things will get rebuilt which don't need to get rebuilt (resulting
in a mongo patch, which we're trying to avoid).
One solution is "p4 obsolete file#head". It would certainly fix the
problem, but I'm reluctant to use obliterate for all the commonly
cited reasons why it's not a good idea. Other ideas we've thought of
1) Building a complex client spec which specifically maps the
"correct" revision of the offending file. This should work, but it
would be a special case in our patch process, and special cases tend
not to mix well with reproducible processes.
2) Creating a new branch starting with the correct revisions of
everything and using that as our new release branch. Again, I think
this works, but becomes an exception to the normal process going
Anybody have any better ideas how to recover?
Roy Smith <smith_roy at emc.com>
Software Guy, EMC Common Management Group
44 South Broadway, 7th floor
White Plains, NY 10601
+1 914 580 3427
More information about the perforce-user