[p4] Using changelists instead of labels for nightly builds

Nau, Michael Michael.Nau at pyxis.com
Wed Mar 9 12:26:27 PST 2005


Thanks for the tip about potential performance impacts.

We were actually doing 'p4 changes -m1' in the beginning. We moved to a
more fine-grained query so our build process would only rebuild a
particular module if it had changed.

For example the latest changes relating to //depot/main/foo/... may be
5000. But the latest change to the entire server may be 5004. We didn't
want to rebuild //depot/main/foo/... unless it had been changed since
our last automated build.

Mike.

-----Original Message-----
From: Kevin Wang [mailto:rightsock at gmail.com] 
Sent: Wednesday, March 09, 2005 12:19 PM
To: Nau, Michael
Cc: perforce-user at perforce.com; FawadKhan at airgonetworks.com
Subject: Re: [p4] Using changelists instead of labels for nightly builds

Note that for really large //depot/main/foo/...'s it's going to be slow,
since perforce has to first walk all the files, and then it can give you
a change#.  You could just as legally and correctly do 'p4 changes -m1'.
While the number won't match a change under that branch, it will still
be a "fixed point and time".

To generally answer the original question:

Changelists are guaranteed to be unmutable (permanent, not editable)
once submitted.  Therefore, using a changeset or datestamp will be the
same for the scenario of an automated build that always just wants the
"latest".

therefore, you could similarly 'p4 sync @2004/12/11:22:33' (You can use
':' to join date and time to eliminate quoting requirements) or p4 sync
@1234 and you'll always get the same result (assuming that change
1234 was checked in at 2004/12/11:22:33).  see "p4 help revisions" for
other ways that you can specify a revision.

Pretty much all perforce commands will take a revision specifier, so you
will need to add it to any other commands you might do for reporting
(filelog, diff, changes).

If you have specific questions, please post them to the
perforce-user at perforce.com mailing list and everyone here will help.

   - Kevin

On Thu, 27 Jan 2005 14:04:15 -0800, Nau, Michael <Michael.Nau at pyxis.com>
wrote:
> Not sure what happened to this reply, so sending again... 
>   
>  ________________________________
>  From: Nau, Michael
> Sent: Tuesday, January 25, 2005 7:05 PM
>  
> We do something similar using changelists instead of labels. Our
process is:
>   
> 1. Run "p4 changes -m 1 -s submitted //depot/main/foo/..." to get the 
> latest submitted changelist for the branch we are building.
> 2. Sync to the changelist from #1
> 3. Build the code on the branch
> 4. Report to results including the changelist # and the perforce path 
> for the code.
>   
> To get the changes since the previous build, you can run "p4 changes 
> -s submitted //depot/main/foo/...@%previous automated build changelist

> #%,@%current automated build changelist #%. This will return the 
> changelist submitted to the branch your building since your last
automated build.
>   
> As long as you have a changelist # and the perforce path for the code,

> you can rebuild at any point in time. This works great for us with 
> automated builds since we don't have to create labels for everything.
>   
> Mike.
>  
>  ________________________________
>  From: perforce-user-admin at perforce.com 
> [mailto:perforce-user-admin at perforce.com] On Behalf Of Fawad Khan
> Sent: Thursday, January 20, 2005 5:22 PM
> To: perforce-user at perforce.com
> Subject: [p4] Using changelists instead of labels for nightly builds
> 
>  
>  
> 
> We are doing multiple automated builds on multiple branches everyday. 
> 
> Every build that happens we create a label and do labelsync for the
records.
> 
> Due to this we have huge number of labels, more than 3K, and because 
> of that
> 
> our db files are huge. We do purge the labels once in a while but 
> since it puts
> 
> a lot of strain on the server when trying to delete labels we do that 
> once in a while.
> 
>  
> 
> I have been told that one can achieve the same goal of record keeping 
> with
> 
> changelists. But, not sure how to go about implementing this in our 
> environment.
> 
>  
> 
> My reasons for creating labels are as follows: 
> 
>  
> 
> *         All our build scripts create a label and then sync to that
label
> in order to avoid a
> 
> situation where checkins are coming in while I am doing a sync for an 
> official build.
> 
>  
> 
> *         Report changes in every build that happened since the last
label 
> 
>  
> 
> *         Be able to sync to that label on a later date and recreate
the
> same build if needed. 
> 
>  
> 
> *         Uniquely identify every build. 
> 
>  
> 
> I wanted to find out other folks are using this on a daily basis and 
> see if we can use the same strategy before.
> 
>  
> 
> Thanks,
> 
> Fawad






More information about the perforce-user mailing list