3 messages in com.perforce.perforce-userIs sync "atomic"?| From | Sent On | Attachments |
|---|---|---|
| Kevi...@Auspex.Com | 30 Dec 1997 16:21 | |
| Jeff...@uplanet.com | 30 Dec 1997 19:01 | |
| Chri...@perforce.com | 31 Dec 1997 11:57 |
| Subject: | Is sync "atomic"? |
|---|---|
| From: | Jeff...@uplanet.com (Jeff...@uplanet.com) |
| Date: | 12/30/1997 07:01:52 PM |
| List: | com.perforce.perforce-user |
At 04:21 PM 12/30/97 -0800, you wrote:
I understand that the "p4 submit" command is atomic and results in a consistent set of sources being checked into the depot all at once. This is Goodness.
What's less clear to me is whether "p4 sync" will give me a consistent set of sources if I am retrieving the head revisions of a very large number of files.
I believe that the first thing that "p4 sync" (aka "p4 get") does is create the list of files/revisions it needs to be up-to-date. That can be done quickly, locking the database as needed. *Then* it gets the files.
Someone from Perforce, Inc. can say for sure. When I started at this company, they were using "Code Manager" (a half-hearted attempt at an SCCS front-end from Sun) and it insisted on locking the entire depot for the duration of a "get". In other words, people didn't run "at the top revision" because to get there was a 30+ minute operation that locked everyone out of the depot. (What a piece of junk.)
I think that Perforce deals with this fairly well...
-jab
ps. If you really, truly are frightened of people getting the "top revision" you can always have a "safe and tested" label that people sync to. Then you update the label as you gain confidence in newer revisions of files...