6 messages in com.perforce.perforce-user[p4] Re: determining the status of a ...| From | Sent On | Attachments |
|---|---|---|
| sandy currier | 02 Nov 2001 08:17 | |
| Rick Macdonald | 02 Nov 2001 09:05 | |
| Michael Go | 02 Nov 2001 09:26 | |
| Rick Macdonald | 02 Nov 2001 09:47 | |
| Debby Dart | 02 Nov 2001 09:57 | |
| sandy currier | 04 Nov 2001 00:32 |
| Subject: | [p4] Re: determining the status of a clientspec |
|---|---|
| From: | Michael Go (mich...@wrq.com) |
| Date: | 11/02/2001 09:26:48 AM |
| List: | com.perforce.perforce-user |
I think Sandy's speaking of other files, i.e., files not included in that particular user's changelist(s). Files that other developers may have changed.
- Mike
-----Original Message----- From: Rick Macdonald [mailto:rickm at vsl.com] Sent: Friday, November 02, 2001 9:06 AM To: sandy currier Cc: perforce-user at perforce.com Subject: Re: [p4] Re: determining the status of a clientspec
On Fri, 2 Nov 2001, sandy currier wrote:
The maximum 'time consistant cross-section' changelevel is that last changelevel sync that was done across the entire client.
Why is this important? Because of the following typical scenerio:
1) developer syncs to head 2) edits stuff, verifies stuff 3) without syncing again, submits change
At this point, the client has a time inconsistant cross-section in that the submitted files are at the head, but any changes between step 1 and step 3 are missing. p4ics.pl will print this condition with interesting details.
I don't quite understand. Perforce schedules for resolve those files that changed between 1 and 3 so you can't really submit them until you resolve them. Why do you say the changes are missing?
...RickM...
_______________________________________________ perforce-user mailing list - perforce-user at perforce.com http://maillist.perforce.com/mailman/listinfo/perforce-user