[p4] p4patch tool? - Stephen Vance - com.perforce.perforce-user

10 messages in com.perforce.perforce-user[p4] p4patch tool?

From	Sent On	Attachments
Kaelin Colclasure	11 Jul 2001 18:26
Steve Cogorno	12 Jul 2001 10:47
Chuck Karish	12 Jul 2001 11:38
Kaelin Colclasure	12 Jul 2001 11:52
Kaelin Colclasure	12 Jul 2001 12:01
Gareth Rees	12 Jul 2001 12:13
Gareth Rees	12 Jul 2001 12:51
barries	12 Jul 2001 13:26
Stephen Vance	12 Jul 2001 18:10
Jeremy Fitzhardinge	14 Jul 2001 15:32

Subject:	[p4] p4patch tool?
From:	Stephen Vance (ste...@vance.com)
Date:	07/12/2001 06:10:36 PM
List:	com.perforce.perforce-user

I'm using the Perforce diff / tech note #2 approach to maintain a parallel copy of the Apache source tree for some personal projects. It's not quite as large as the Linux kernel tree, but still pretty substantial. I've had no problems to date, and would use the same techniques if I wanted to maintain a kernel tree. The biggest gotcha is making sure you don't accidentally add object files and the like, but applying the patch against a fresh client, separate from your build client, makes it a non-issue.

Steve

At 11:52 AM 7/12/2001 -0700, Kaelin Colclasure wrote:

Steve Cogorno wrote:

Kaelin Colclasure said:

I am contemplating trying to keep a Linux kernel tree in Perforce in sync with the latest kernel releases from kernel.org. When a new kernel comes out, a patch is prepared against the previous version of the kernel. I am wondering if anyone has perhaps built a Perforce-aware version of `patch'? Such a tool would: * `p4 edit' files updated by the patch * `p4 add' files introduced by the patch * `p4 delete' files obsoleted by the patch (if indeed you can delete a file in a patch) I'm thinking this would be considerably less error-prone than the alternative of using `p4 diff -se', etc. to try to figure out everything the patch did *after* the fact...

Actually, p4 diff is the way to go. I have a simple shell script that compares a client against the depot. I'll paste it below. Use the -update flag to issue the p4 commands. If you don't use -update, then the program merely reports the difference.

Steve,

The problem with this approach for a beast like a Linux source tree is that there's a high likelyhood of ``exteraneous files'' lying about in the directory structure. Yes, yes... a `make clean' (or some variation thereof) *should* take care of all that -- but who is going to whip all those kernel hackers and device driver authors into conformance... :-)

Thanks for the suggestion, though.

-- Kaelin