17 messages in com.perforce.perforce-user[p4] checkpoints/backups| From | Sent On | Attachments |
|---|---|---|
| sandy currier | 27 Jan 2000 13:25 | |
| Richard Geiger | 31 Jan 2000 09:53 | |
| Andrew Dalgleish | 31 Jan 2000 14:57 | |
| Dave Lewis | 31 Jan 2000 15:06 | |
| Chuck Karish | 31 Jan 2000 17:18 | |
| David Jeske | 01 Feb 2000 05:47 | |
| Andrew Dalgleish | 01 Feb 2000 14:56 | |
| Dave Lewis | 01 Feb 2000 15:43 | |
| Chuck Karish | 01 Feb 2000 15:56 | |
| Andrew Dalgleish | 01 Feb 2000 16:03 | |
| Michael Graff | 01 Feb 2000 16:17 | |
| Chuck Karish | 01 Feb 2000 17:35 | |
| David Jeske | 01 Feb 2000 23:43 | |
| Chris Bartz | 02 Feb 2000 09:30 | |
| Andrew Dalgleish | 02 Feb 2000 13:38 | |
| Andrew Dalgleish | 02 Feb 2000 14:04 | |
| Jeff A. Bowles | 03 Feb 2000 04:36 |
| Subject: | [p4] checkpoints/backups |
|---|---|
| From: | Chuck Karish (chuc...@weblogic.com) |
| Date: | 02/01/2000 03:56:53 PM |
| List: | com.perforce.perforce-user |
At 02:56 PM 2/1/00 , Andrew Dalgleish wrote:
It works this way, because it will safetly handle (and ignore) checkins which are "extra" in the RCS files. If foo.c#4 was in the RCS files but not in the checkpoint, then it simply would not appear, and when you checked in "foo.c#4", it would overwrite the previous data in the RCS file and your depot would be clean as a whistle.
[Andrew Dalgleish] It might safely ignore any extra revisions in the RCS, but I still call that lost data. I prefer to stop the server, so the users *know* that their revisions are not in the depot.
Scenario: The user does a checkin and deletes the files from their workstation. The admin does a restore and the depot throws the users most recent revision(s) away.
Can anyone explain to me why this is considered a good idea? Or call it "safe" handling?
The admin restores a backup. Changes made after the datum for the backup are lost. What's especially unsafe about this?
The safest way is to stop the server. If downtime is an issue then use a file system which can take a fast snapshot.