[p4] Changes since last label - Mich...@diversifiedsoftware.com - com.perforce.perforce-user

13 messages in com.perforce.perforce-user[p4] Changes since last label

From	Sent On	Attachments
Mich...@diversifiedsoftware.com	24 Apr 2001 10:41
Diane Holt	24 Apr 2001 12:33
Jeff A. Bowles	24 Apr 2001 14:45
Mich...@diversifiedsoftware.com	24 Apr 2001 14:56
Mike Castle	24 Apr 2001 15:36
Diane Holt	24 Apr 2001 15:43
Diane Holt	24 Apr 2001 15:43
Diane Holt	24 Apr 2001 15:48
Mich...@diversifiedsoftware.com	24 Apr 2001 16:05
Mike Castle	24 Apr 2001 16:29
Diane Holt	24 Apr 2001 17:10
Mich...@diversifiedsoftware.com	24 Apr 2001 17:42
Jeff A. Bowles	24 Apr 2001 18:09

Subject:	[p4] Changes since last label
From:	Mich...@diversifiedsoftware.com (Mich...@diversifiedsoftware.com)
Date:	04/24/2001 04:05:34 PM
List:	com.perforce.perforce-user

Instead of "p4 counter change", try something like "p4 changes -m1 ./..." which will tell you the last change number you synced in this client.

Mike Castle <mcastle at yy.com>@perforce.com on 2001-04-24 15:37:14

Sent by: perforce-user-admin at perforce.com

To: Perforce Users List <perforce-user at perforce.com> cc: Subject: Re: [p4] Changes since last label

On Tue, Apr 24, 2001 at 02:46:09PM -0700, Jeff A. Bowles wrote:

Now, using a (pathname, changenumber) combination is sufficient to represent a release. Always. (I disagree with Diane on this part.) But

Not always.

handoff #1: build out of the normal development codeline, identified as "//depot/devline/... at 12367".

Let's say you also are required to archive the results of the build process. You either have to branch immediately, and protect that branch, or you have to use labels. Otherwise you have a race condition:

p4 sync p4 edit build.results build Another developer makes a change p4 submit build.results echo "You just built `p4 where ... | awk '{print $1}'` at `p4 counter change`"

Of course, that isn't sufficient, because the changes the other developer made are not part of this build.

mrc