From owner-p4-projects@FreeBSD.ORG Tue Jun 13 09:53:46 2006 Return-Path: X-Original-To: p4-projects@freebsd.org Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 6DC7216A41A; Tue, 13 Jun 2006 09:53:46 +0000 (UTC) X-Original-To: perforce@FreeBSD.org Delivered-To: perforce@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F99516A41B; Tue, 13 Jun 2006 09:53:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id B114A43D45; Tue, 13 Jun 2006 09:53:45 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 40DD846C34; Tue, 13 Jun 2006 05:53:45 -0400 (EDT) Date: Tue, 13 Jun 2006 10:53:45 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Tom Rhodes In-Reply-To: <20060612165259.0164738d.trhodes@FreeBSD.org> Message-ID: <20060613104537.U34121@fledge.watson.org> References: <200606122043.k5CKhU1Y008373@repoman.freebsd.org> <20060612165259.0164738d.trhodes@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: perforce@FreeBSD.org Subject: Re: PERFORCE change 99079 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 09:53:46 -0000 On Mon, 12 Jun 2006, Tom Rhodes wrote: > On Mon, 12 Jun 2006 20:43:30 GMT > Tom Rhodes wrote: > >> http://perforce.freebsd.org/chv.cgi?CH=99079 >> >> Change 99079 by trhodes@trhodes_local on 2006/06/12 20:35:11 >> >> If the login.conf file is not root:wheel, the configuration >> in login.conf.db will not be applied. This can sometimes >> happen when replicating configuration across hosts using >> a user account and scp. Add a check for this. >> >> Affected files ... > > Ummm, it also included my integrate. The check file is > src/periodic/security/410.logincheck. Integration schedules merging of changes, and with the help of resolve, makes them appear and merge into your local branch. Like edit, add, and delete, the results of that operation are local to your work tree until submitted. This is why you see perforce messages that read "IFC" -- this means "Integrate From Current", and refers to integrating the latest CVS source into a branch as an explicit operation. The typical integrate sequence for a branch is one or more runs of p4 integ, one or more runs of p4 resolve -a , p4 resolve, p4 submit. The "one or more" bit is so that you can catch error conditions and provide additional flags or perform additional resolution as required. For example, p4 will occasionally tell you you need additional flags if a delete in the parent branch would delete a file that has changes in the child branch, or if a file is added to the parent branch after an identically named file is added to the child branch. In general, you don't want to combine submitting integrations with other edits, as it results in a significantly harder to read source history. For example, it's quite useful to be able to submit a change to P4, wait a few weeks, then merge it to CVS. If the change didn't require any refinement, you can do "p4 describe -du changenumber" and generate the description and patch for the change. If you combine branch integration with the edit, then you get the integration patch also, which will be unhelpful in your merge efforts. There are times when editing as part of an integrate will be required -- such as if you resolve the tree of conflicts, do a test build before submitting, and discover a typo in the resolve. Also, for minor changes, you may find that a personal user branch, such as //depot/user/trhodes/work/... avoids spamming the larger community. Typically, //depot/projects/... has been used for larger (potentially collaborative) projects that are long-running. By default, developers are set up with reviews on //depot/projects/..., //depot/user/{username}/..., and //depot/doc/.... Changes made to local user trees aren't seen by other users unless those users specifically subscribe to them. Robert N M Watson Computer Laboratory Universty of Cambridge