On 07-Aug-01 Julian Elischer wrote:
> I have pushed the thread pointers down through most of the code
> though there are still many many places that assume that there is only one
> thread per process. (no multithreading yet, but getting closer..)
> At this stage diffs must be pushing close to 1MB (maybe more)
> (I don't know as I don't know yet how to get p4 to generate diffs :-)

It's not too hard.  I have the smpng and jhb_preemption batches updating
diff's on freefall via cron. :)

To do a diff of files against files you have checked out, you use 'p4 diff'
such as 'p4 diff -du ...' to get a unified diff.  Unfortunately, p4's diff
format isn't too patch friendly.  There is also a 'p4 diff2' which does a
diff of files in the depot.  p4 diff2 has an undocumented (well, it's
documented in 'p4 help undoc') option -u that will produce a unified diff that
patch can grok (albeit, it has the full depot path, so you'll have to use -p6
or some such to apply it).  If you had a julian_kse branch off of the kse
branch you would use 'p4 diff2 -u -b julian_kse' to get a diff of the entire
branch.  You can use 'p4 diff2 -u -b kse' to get a diff of the kse branch
against the head, but unfortunately it does a diff against the head of the
-current vendor import rather than against the latest files you last integrated

To make the diff relative to when you last branched, you can use a revision
specification to refer to the state of the -current tree when you last did your
integrate.  To do this, look up the change number of your last integrate from
-current, (right now 448 was your last MFC for example).  You then generate a
diff between -current as of that change number and the head revision of your
branch (see 'p4 help revisions' or the revisions section of the quickstart
guide) like so:

> p4 diff2 -u -b kse @448 #head

However, having to look up the change number for diff's is a minor pain, and
makes it harder to automate things (like generating diff's in crontabs).
What you can do is create a label that tracks -current and is the last
branch point.  First, you want to create a label whose View is the same as the
files your branch branches from.  For example:

> p4 branch -o smpng
Branch: smpng
        //depot/vendor/freebsd/sys/... //depot/projects/smpng/sys/...
> p4 label -o smpng_base
Label:  smpng_base
        Label that tracks the smpng branch's 'base', i.e. the last
        change imported from the FreeBSD current branch.

You use 'p4 label' to create a label (set its View, description, etc.)  You use
'p4 labelsync' to actually determine what revisions of what files the label
applies to.  If you created a kse_base label, then you would start off by
specifying it as the last change you integrated from (448) like so:

> p4 labelsync -l kse_base @448

You can then do diff's like so:

> p4 diff2 -u -b kse @kse_base #head

Keeping the label up to date is fairly easy.  When you want to do an integrate,
simply follow these steps:

> p4 labelsync -l kse_base #head
> p4 integrate -b kse @kse_base
> p4 resolve -a
> p4 resolve
> p4 submit

Note that you can update the label of individual files as well if you wish. 
For example, my last integrate into smpng just brought across a commit to
sys/i386/isa/ipl.s rather than updating the entire tree:

> p4 integrate -b smpng sys/i386/isa/ipl.s
> p4 resolve -a
> p4 submit

I then updated the label on just that file like so:

> p4 labelsync -l smpng_base //depot/vendor/freebsd/sys/i386/isa/ipl.s#head

I usually keep my work trees off of the smpng branch up to date with the smpng
branch, so I don't have to bother with label's on those.  This allows you to
get things working on a stable snapshot of current, and later do an integrate
to catch up.

Note that you could of done the MFC of one file as so:

> p4 labelsync -l smpng_base //depot/vendor/freebsd/sys/i386/isa/ipl.s#head
> p4 integrate -b smpng @smpng_base
> p4 resolve -a
> p4 submit



John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to