22 messages in com.perforce.perforce-user[p4] P4 integration issue/question - ...
FromSent OnAttachments
Chan, Eddie12 Sep 2001 10:06 
Todd Short12 Sep 2001 10:11 
Dave Foglesong12 Sep 2001 10:41 
Rick Macdonald12 Sep 2001 11:36 
Cimarron Taylor12 Sep 2001 12:01 
Jeff A. Bowles12 Sep 2001 12:35 
Rick Macdonald12 Sep 2001 17:23 
Mike Castle12 Sep 2001 17:44 
Rick Macdonald12 Sep 2001 17:45 
Jeff A. Bowles12 Sep 2001 21:10 
"Schaible, Jörg"14 Sep 2001 03:27 
Dave Lewis14 Sep 2001 07:39 
Rick Macdonald14 Sep 2001 08:29 
Dave Foglesong14 Sep 2001 08:32 
Dave Lewis14 Sep 2001 08:45 
Karl Philipp14 Sep 2001 09:03 
Matt Harp14 Sep 2001 09:12 
Stephen Vance14 Sep 2001 09:13 
Stephen Vance14 Sep 2001 20:37 
Chuck Karish15 Sep 2001 10:53 
Chuck Karish15 Sep 2001 11:08 
Stephen Vance17 Sep 2001 08:01 
Subject:[p4] P4 integration issue/question - Please confirm
From:Jeff A. Bowles (ja@pobox.com)
Date:09/12/2001 12:35:40 PM
List:com.perforce.perforce-user

At 12:36 PM 9/12/2001 -0600, Rick Macdonald wrote:

It really sounds like perforce should not allow "reopen for edit" when a file is open for "branch", don't you think?

Short answer: nope, it's handy sometimes.

Background follows.

If you open a file using p4 integrate parent/x.c child/x.c (and the child version doesn't exist yet) then you've opened it for "branch" - to make a "first copy" into the branch. It'll be a lazy copy when you submit it, which is slick.

But sometimes you really need to make a change to child/x.c before submitting it. The best example I can think of is when you're copying x.java to make y.java, using x.java#5 as the content to create y.java#1.

[The rest of this e-mail will talk about x.java and y.java since that's the best example I can think of that would use the 'downgrade to add/edit' feature.]

Remember that x.java defines class x, y.java defines class y. That's a Java naming convention.

So you really don't want to check in y.java without changing the line INSIDE THE FILE to be "class y ......." because if you don't make this change, y.java#1 is guaranteed to be unusable until re-edited.

If you read "p4 help integ" closely, you'll see some verbiage about "downgrade to add" or "downgrade to edit". That is a way to OFFICIALLY tell Perforce that you're hacking the file locally before the submit, so it should do two things: 1. realize that the on-disk copy in your workspace is the content you want for y.java#1; 2. Make notes into the metadata that make it clear that x.java#5 was the parent of y.java#1, but that there was more hacking done locally. 3. (Three things, not two. Sorry.) It also will notice that the hacked stuff ("class y ....." in this example) will eventually want to be propogated back to the parent, and the first reverse-integrate will try to do that. The sequence to do this is to run: p4 integ x.java#5 y.java (note, don't submit yet) p4 add y.java (hack the file) p4 submit or, if the file exists already, you'd use "p4 edit" as the second step.

It looks a bit weird at first, but makes a bit of sense when you think about it.

Most situations don't require/need this. Header files with hard-coded version strings, Java class files, those are the situations that might want this.

-Jeff Bowles Perforce Consulting Partner