PERFORCE change 99079 for review

[Robert Watson]

On Mon, 12 Jun 2006, Tom Rhodes wrote:

> On Mon, 12 Jun 2006 20:43:30 GMT
> Tom Rhodes <trhodes at freebsd.org> wrote:
>
>> http://perforce.freebsd.org/chv.cgi?CH=99079
>>
>> Change 99079 by trhodes at 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