Suppose That 2 different branches include a file that is exactly the same, except its revision number.
How can I force "p4 integrate" to automatically take the higher-revision branch without using "p4 resolve"?
Thanks.
Related
Suppose we have a single text file in 2 branches:
//depot/work/branch1/file.txt
//depot/work/branch2/file.txt
We also have a central source file here that both branches depend on.
//depot/work/ImportantFile.txt
I make local edits to ImportantFile.txt and branch1/file.txt, but I also want to duplicate those edits to branch2/file.txt because ImportantFile.txt now expects all branches of file.txt to conform to a certain specification. As far as I know I have only 2 options, neither of which are ideal:
Manually make the same edits on both files and submit both changes in a single changelist. The problem with this, is that I would like P4 history to know that these files are still 100% integrated, but the history will show that they were edited independently.
Only make edits to branch1/file.txt, submit just this file as well as ImportantFile.txt in one changelist, then immediately integrate the change to branch2/file.txt in a 2nd changelist. Now the problem is that I've broken the build for a minute or two until branch2/file.txt gets the required changes.
How can I edit a file, and directly integrate those edits to another file before I submit those edits to the first file?
First off: you may already know this (and have had to make peace with it for reasons beyond your control) but:
ImportantFile.txt should not be outside of your branching structure. If your versioned files depend on it, it needs to be versioned itself, and that means it needs to exist independently in each branch, because branches are a part of your versioning scheme. Alternatively, maybe file.txt should not be branched, if it's required that it be identical in all branches at all times -- why branch something that's not allowed to diverge? But I suspect that just branching everything is the better solution.
Now for the workaround. (If you can't fix the root cause as described above, you've probably got a lot of this sort of thing in your future.)
p4 copy //depot/work/ImportantFile.txt //depot/work/NotABranch/ImportantFile.txt
p4 copy //depot/work/branch1/file.txt //depot/work/NotABranch/file.txt
p4 submit -d "Not a branch! (wink)"
Make your edits in //depot/work/NotABranch and submit them. Nothing is broken because, as stated, this is not a branch, and so it's exempt from whatever policy it is that forces all branches to move in lockstep. Now you can do:
p4 integ //depot/work/NotABranch/ImportantFile.txt //depot/work/ImportantFile.txt
p4 integ //depot/work/NotABranch/file.txt //depot/work/branch1/file.txt
p4 integ //depot/work/NotABranch/file.txt //depot/work/branch2/file.txt
p4 resolve
p4 submit
The merge history shows that both branches of file.txt were pure merges from a single common source, and so future integrations between the two should recognize that they don't need to be re-merged.
P4D/LINUX26X86_64/2013.2/938876 (2014/09/23)
I had some changes in the default changelist that I tried to shelve. It said I couldn't because I needed to resolve with some other changelist. It stuck my files in some other changelist. After looking at the differences, I saw that I wanted to keep all my changes and accept nothing from the other changelist. Thinking that "-am" meant "accept mine", I ran "p4 resolve -am". Then there was a "Duuuuhhhhh" momemt when I remembered that "-am" means "auto-merge".
Q: How can I "undo" the automerge that just happened so as to restore what I had ?
If you were able to shelve successfully at some point you can get the pre-resolve files back from the shelf via "p4 unshelve".
As a general rule you can't undo the results of a resolve operation to get the "yours" file back, since the workspace file isn't backed up anywhere.
Since this was an automerge, one option would be to try to run the merge in reverse. You started with A(base)+AB(theirs)+AC(yours), and now you have ABC(merged) -- so you want to set up a merge that'll produce AC. That'd be AB(base)+A(theirs)+ABC(yours)=AC(merged) -- basically you want to find the "base" and "theirs" from the automerge and reverse them, using the merged result as "yours". Run "p4 resolved -o" to find the "base" and "theirs" file from the previous merge, then run "p4 print" to get those file contents and use "p4 merge3" to run the 3-way merge algorithm with the three appropriate inputs and the output should be your original file (in theory).
I'm having trouble performing a merge/integrate from branch1/sql/ to b2/sql
I performed a rename operation in p4v from _1.sql to _2.sql
Made a small change to _2 file
Submitted changes
Went to submitted changes, and tried to perform a merge/integrate on _2 to the other branch (b2/sql).
The problem is that p4v freezes at that point:
What am I doing wrong ?
BTW, I have the latest version: Version: Helix P4V/NTX64/2018.2/1666551
Based on the generated changelist description, P4V appears to be hopelessly confused and trying to integrate the file into itself rather than between the two different branches you specified.
Easiest fix is to run it from the command line:
p4 merge //depot/Engineering/INT-DEV/...#=CHANGE //depot/Engineering/projects/...
where CHANGE is the small change you're trying to merge (this is easier/safer than specifying the full file path, especially if you're dealing with a file that got renamed in one branch but not the other since it's otherwise easy to mess up entering one of the paths).
If the small change is the only change you've made since the last merge, you can just trust p4 to figure that out automatically and do this very simple command instead:
p4 merge //depot/Engineering/INT-DEV/... //depot/Engineering/projects/...
Here's the scenario -
Development branch was created from mainline, with many thousands
of files in it
A couple of thousand files were modified.
Changes from mainline were "p4 integrated" into the branch.
Hopefully integrations always included the complete mainline as of a
known-good label, but I'm not sure of this
Steps 2 and 3 were repeated an unknown number of times - let's guess
a dozen integrates, and probably another 1000 or more changes,
usually to files already modified
I am now in the painful position of trying to code review this.
Are there any commands that can help me get the diffs for each modified file between the version last integrated to it, and the version in the branch?
Or do I need to write:
A script which will identify all locally changed files.
A script which will find the integration point for each file in the above list
Another script which will use (2) to purge the list in (1) of files with no net change
A wrapper on (2) that will issue an appropriate p4 diff2 command
FWIW, I basically know how to do this manually, file by file. It's the scale that's daunting. Also, there are changes still going into the branch, in response to code review feedback, so I'll probably be recreating my lists repeatedly.
If you know what the known-good label in the mainline was that was used to do the last integrate, this should just be:
p4 diff2 main/...#good-label dev-branch/...
since for each file "the version last integrated" will be #good-label. Files that weren't locally modified won't have any diffs, so there's no special need to filter them out.
FWIW if I were in your position I'd be making use of "p4 ichanges dev-branch/... main/..." and going through by changelist, since diffs make more sense when each is in the context of its changelist, rather than looking at one monster diff per file that each contains a dozen unrelated changes.
I have a file on another branch which contain a change I would like to integrate. But it contains other changes too which I don't want to integrate yet.
How can I integrate the file only partially?
I first integrated and resolved the file as usual, then I did a "p4 edit" on the file after that to remove the changes I don't want to go in yet. "p4 opened" said that the file is opened for edit, so I thought the commit will submitted as an edit not an integration. I was wrong! It still updated the integration history! So if I attempt to integrate the rest of the changes later the perforce will say "all revisions integrated", and the only way to resolve the problem is integrating by disregarding the integration history, which is painful to resolve.
How can I avoid this next time?
EDIT:
To clarify I mean there are multiple changes in a single revision of file and I want to integrate only a part of it.
(edited to reflect that the question is about partially integrating a revision, not integrating a single revision of a file)
Since a revision is the smallest atom of change in Perforce's metadata, you won't be able to record that a subset of a revision was integrated -- and since you don't want to record that the entire revision was integrated (thereby "ignoring" the rest of the revision for future integrations), rather than doing this as an integrate, I'd do it as an edit:
p4 edit target
p4 print -o theirs source#n
p4 print -o base source#n-1
p4 merge3 base theirs target > target
rm base theirs
(edit target)
p4 submit
Another option would be to initially open the file for integrate and then clear the resolve record by reverting (use the -k flag to keep local changes) and reopening for edit:
p4 integrate source#n,n target
p4 resolve
p4 revert -k target
p4 edit target
In general if there are multiple independent changes you're making to a file such that you might want to be able to cherry-pick and/or track them independently at a later date, submitting them as independent changelists will make that much much much easier. Shelving can help with this if you realize only after making a big change that it'd make more sense as a series of smaller changes -- shelve your big change, revert some parts, submit the smaller change, then unshelve the big change and continue.