13 messages in com.perforce.perforce-user[p4] Production environment questions
FromSent OnAttachments
Dan Kegel06 Apr 2002 16:01 
Dan Kegel08 Apr 2002 19:33 
Robert Cowham09 Apr 2002 00:41 
Chuck Karish09 Apr 2002 07:13 
ste...@vance.com09 Apr 2002 09:26 
Diane Holt09 Apr 2002 10:02 
Steve Smythe09 Apr 2002 10:56 
Dan Kegel09 Apr 2002 10:58 
Diane Holt09 Apr 2002 11:00 
Dan Kegel09 Apr 2002 12:12 
Dan Kegel09 Apr 2002 12:31 
Dan Kegel09 Apr 2002 12:40 
ste...@vance.com09 Apr 2002 15:04 
Subject:[p4] Production environment questions
From:Dan Kegel (da@kegel.com)
Date:04/09/2002 10:58:07 AM
List:com.perforce.perforce-user

Diane Holt wrote:

--- steve at vance.com wrote:

If it's feasible in your situation, you can integrate, build, test and then either revert or submit based on the outcome. This will achieve the results you are asking for.

I'd recommend: build, test, then either integrate or reject.

Unfortunately, in our environment, a complete test is often not feasible to do on the developer's workstation because it requires access to hundreds of thousands of dollars of equipment. The developer will indeed test before committing, but only on the hardware at hand. The nightly autobuild runs regression tests on all the hardware, and about three days a week lately, some of the tests fail for one reason or another.

We fuzzily thought we could reduce the number of failures by doing two nightly autobuilds - one of the development codeline, and one of a stable codeline - and propagate changes from development to stable once they prove themselves, and revert them if they turn out to break stable.

My question was something like "How hard is it to push changesets from one branch to another individually, and are they hard to track when you do this, especially if you revert some of them?" Robert Cowham spoke to this a bit, and I'll reply to his message next.

Thanks to everyone who replied! - Dan