Date: Tue, 13 Jun 2006 10:53:45 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Tom Rhodes <trhodes@FreeBSD.org> Cc: perforce@FreeBSD.org Subject: Re: PERFORCE change 99079 for review Message-ID: <20060613104537.U34121@fledge.watson.org> In-Reply-To: <20060612165259.0164738d.trhodes@FreeBSD.org> References: <200606122043.k5CKhU1Y008373@repoman.freebsd.org> <20060612165259.0164738d.trhodes@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 12 Jun 2006, Tom Rhodes wrote: > On Mon, 12 Jun 2006 20:43:30 GMT > Tom Rhodes <trhodes@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060613104537.U34121>