6 messages in com.perforce.perforce-userbacking out changes?| From | Sent On | Attachments |
|---|---|---|
| Dave...@vignette.com | 15 Oct 1998 08:56 | |
| Sully | 15 Oct 1998 09:35 | |
| Ping...@mit.edu | 15 Oct 1998 09:42 | |
| Dave...@vignette.com | 15 Oct 1998 13:30 | |
| Fred...@mydata.se | 15 Oct 1998 14:43 | |
| Ping...@mit.edu | 15 Oct 1998 17:26 |
| Subject: | backing out changes? |
|---|---|
| From: | Fred...@mydata.se (Fred...@mydata.se) |
| Date: | 10/15/1998 02:43:19 PM |
| List: | com.perforce.perforce-user |
First I want to join the choir that says: don't mess with history unless You have to. It is so easy to check out the previous version and submit it with a change comment "Ooops! Sorry, change XXXX is now reverted". Not something to bother an administrator with.
That said: I have some experience in this field (p4 crashed and left corrupted metadata so I had to do some experimenting to get it back on track).
Dave Lewis wrote:
can obliterate be used to remove a specific version of a file, such as file#2 leaving file#1? No.
My impression is that it only removes files, and would not apply to revisions. Correct.
On a fairly regular basis, people come to me asking if they can remove or back out a change they have submitted. I always tell them they can only fix it with another submit of the files they really want.
I know if we were desperate, we could probably edit the db files or checkpoint, but that's a major inconvenience (our checkpoint runs at midnight, and users have mentioned how inconvenient it is!)
This is where it gets interesting. A change is recorded in the metadata AND in the data file in the depot. My question was: can You just remove the change from the metadata? And the answer is: Yes You can. P4 seems to handle this. The change is forgotten and it is possible to make new changes to the file.
In my case I lost the journal file so all changes made that day was lost. This was not a major problem since I could still read the corrupted journal file and find out who had made any changes. Those people still had a copy of the code so it was easy to for them to submit it again.
I guess the procedure might be to truncate the journal file to before their change, then restart with the checkpoint and journal, of course if the change was not the last one, others would be lost.
Truncating the journal file is a bit too _interesting_ for my taste, but probably possible. I guess that You could even remove a specific change if You wanted to but I would not risk the depot for this....
WARNING One, possibly unexpected, problem that You get when You restore an old checkpoint but not the journal file is that the have-list in the metadata does not reflect what the users think. It confuses users when files that was opened for edit can not be submitted. This looks harmless but it might actually be a killer. P4 keeps all files at the user write protected to mark them as "not opened". If a file is not write protected but not opened p4 can: a) overwrite when sync or b) leave untouched when sync This depends on the client options. Default is b) (noclobber). The user may not notice but he has a file that will not be updated when modified by other users. P4 prints a warning but.... I think "p4 sync -f" will fix the problem, but this will also destroy any local copy of the changes that where lost in the depot.
/Fredric
--- Fredric Fredricson MYDATA automation AB Manager System SW R&D Adolfsbergsvagen 11 phone: +46 8 475 55 21 S-161 70 BROMMA fax: +46 8 475 55 01 SWEDEN email: fredric at mydata.se http://www.mydata.se