22 messages in com.perforce.perforce-user[p4] P4 integration issue/question - ...| From | Sent On | Attachments |
|---|---|---|
| Chan, Eddie | 12 Sep 2001 10:06 | |
| Todd Short | 12 Sep 2001 10:11 | |
| Dave Foglesong | 12 Sep 2001 10:41 | |
| Rick Macdonald | 12 Sep 2001 11:36 | |
| Cimarron Taylor | 12 Sep 2001 12:01 | |
| Jeff A. Bowles | 12 Sep 2001 12:35 | |
| Rick Macdonald | 12 Sep 2001 17:23 | |
| Mike Castle | 12 Sep 2001 17:44 | |
| Rick Macdonald | 12 Sep 2001 17:45 | |
| Jeff A. Bowles | 12 Sep 2001 21:10 | |
| "Schaible, Jörg" | 14 Sep 2001 03:27 | |
| Dave Lewis | 14 Sep 2001 07:39 | |
| Rick Macdonald | 14 Sep 2001 08:29 | |
| Dave Foglesong | 14 Sep 2001 08:32 | |
| Dave Lewis | 14 Sep 2001 08:45 | |
| Karl Philipp | 14 Sep 2001 09:03 | |
| Matt Harp | 14 Sep 2001 09:12 | |
| Stephen Vance | 14 Sep 2001 09:13 | |
| Stephen Vance | 14 Sep 2001 20:37 | |
| Chuck Karish | 15 Sep 2001 10:53 | |
| Chuck Karish | 15 Sep 2001 11:08 | |
| Stephen Vance | 17 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




