23 messages in com.perforce.perforce-user[p4] Labels or branches?
FromSent OnAttachments
mj...@panasas.com04 Jun 2001 21:20 
Mike Castle04 Jun 2001 22:04 
Chuck Karish05 Jun 2001 00:54 
Robert Cowham05 Jun 2001 01:43 
Matthew Rice05 Jun 2001 04:39 
Stephen Vance05 Jun 2001 07:20 
Keith Johnson05 Jun 2001 07:37 
Dave Lewis05 Jun 2001 08:09 
Jeff A. Bowles05 Jun 2001 08:14 
Chuck Karish05 Jun 2001 16:35 
Maurice Meyer05 Jun 2001 17:17 
Mike Castle06 Jun 2001 10:32 
Robert Cowham06 Jun 2001 10:55 
Matthew Rice06 Jun 2001 11:37 
Jeff A. Bowles06 Jun 2001 12:45 
Stephen Vance06 Jun 2001 20:09 
Stephen Vance07 Jun 2001 08:28 
Chuck Karish07 Jun 2001 09:33 
Ganesh Kondal07 Jun 2001 15:52 
Stephen Vance07 Jun 2001 18:08 
Chuck Karish07 Jun 2001 21:54 
Paul Goffin08 Jun 2001 00:35 
Stephen Vance08 Jun 2001 07:55 
Subject:[p4] Labels or branches?
From:Stephen Vance (ste@vance.com)
Date:06/08/2001 07:55:02 AM
List:com.perforce.perforce-user

At 09:55 PM 6/7/2001 -0700, Chuck Karish wrote:

At 09:08 PM 6/7/2001 -0400, Stephen Vance wrote:

At 09:34 AM 6/7/2001 -0700, Chuck Karish wrote:

At 11:28 AM 6/7/2001 -0400, Stephen Vance wrote:

[ ...] in the nightly build scenario, you can use a nice, orderly time by convention (say 10PM or 2AM) and, as long as that time is in the past at the time the build is scheduled, it is just as reliable as the changelist and simpler to implement.

Until the first time someone checks in a change at 21:50 that breaks the nightly build. A system that does the nightly build and test against a label or counter corresponding to the last change that had been demonstrated to build cleanly is worth many hours a month of extra sleep for the build master.

This strikes to the two different roles people assign to nightly builds.

I'm sure we can think of more than two different uses!

More clearly stated, the two roles I mean are buildability verification and product testing. In one form or another almost all nightly build scenarios fall under these two rubrics. There are likely others, but these cover the overwhelming majority of real usage. I was focusing more on the "build" aspect of it.

For those using it to verify that the system does build, then test it if that succeeds (just a simple "build the latest of some known state"), time works fine.

What about people who want to run tests every night, whether or not some soon-to-be-popular person broke something late in the evening? Some people who want to do this run builds triggered by the review daemon, and save the change number if the build succeeds.

That falls in the category of testing. Time works well for build verification. Being able to test something regardless of the buildable state of the head revisions is a more complicated problem, thus the need for the review daemon's involvement or other mechanisms. This would also limit you to testing the latest buildable changelist, rather than all of the work that has occurred, which may be an appropriate tradeoff in a context.

It all depends on the needs of the product and the other mechanisms in place to ensure quality. For example, on smaller systems (< 500KLOC) I generally integrate the regression testing framework with the build environment such that a simple build tests at least the entire subset in which the developer is working. With a policy (enforced through peer pressure) of not submitting without a full build, this has worked very well. However, it doesn't allow "instantaneous release," scale to large or distributed systems, or work very well for systems in which the development target is not the development host.

A lot can be said about mechanisms by which SCM can facilitate build engineering. My original point was that date/time-based syncing is a useful mechanism with a different set of properties, from mnemonic and mutability perspectives, than changelists or labels. I failed to fully qualify the contexts in which this is appropriate.

Steve

Stephen Vance mailto:steve at vance.com http://www.vance.com/