So I did a merge through cmd which did not end up well, so I undid that CL (through visual client), now if I try to merge the 2 streams again I get a window saying Integration errors: //project_stream/main/... - all revision(s) already integrated. Does it mean there is no way to do the merge again?
If you undo an integration via p4 undo and the dm.integ.undo configurable is set you can just re-do an integration exactly as you tried to do.
(p4 help undoc)
dm.integ.undo 0 Enable re-integration of undone changes
If those two conditions can't be met (i.e. you did the undo with a version of P4V that doesn't use the native undo command and/or you can't get your admin to flip that configurable setting), you have to re-integrate with the -f flag.
The -f flag forces integration without regard to previous history, which allows you to redo an integration -- however, you need to explicitly tell it which revisions/changelists to integrate, and/or take extra care during the resolve process. Look carefully at the integration records from your original changelist to figure out what the earliest source changelist would have been, and do:
p4 integ -f source/...#SOURCE_START,#now target/...
The revision before SOURCE_START will be used as the base during the resolve process.
Related
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.
I'm getting ready to integrate our "Dev" branch into our "Testing" branch in preparation for an upcoming release.
For our last release, after the initial integration, we determined there were some changes we didn't want to release. I rolled back some files in the Testing branch, and commented out portions of other files. Many of these files haven't changed in the Dev branch, so as far as Perforce is concerned, they've already been integrated and are good-to-go.
Obviously, I could track down the changelists and un-rollback these files. I could also integrate the offending files with the "-f" option to disregard integration history.
But I was hoping to find a way to do this "automatically". I tried integrating the entire branch with "-f", resolving, and then reverting unchanged files, but this just gives the message: <filename> has pending integrations, not reverted.
Is there a way to get Perforce to revert unchanged files that are pending integration? Is there some other approach I should take?
Have you tried the following steps under 'Pending integrations not reverted'?
http://answers.perforce.com/articles/KB_Article/Reverting-Unchanged-Files
Files that are integrated and resolved but have no content or type changes will still be submitted as new revisions, EVEN IF you have 'revertunchanged' selected in your client spec, or use 'submit -f revertunchanged'. This behavior is by design, but is not obvious.
Again, if a submit would change the integration history of a file, then that file is considered changed, even if there are no content changes. In other words, updates to integration history are considered a file change, just like content, type, and attribute changes.
The command line equivalent of the 'revertunchanged' option, p4 revert -a, offers some context. From p4 help revert:
The -a flag reverts only files that are open for edit or integrate
and are unchanged or missing. Files with pending integration records
are left open. The file arguments are optional when -a is specified.
For example:
$ p4 revert -a b
//depot/test/b#1 - has pending integrations, not reverted
Users concerned about integrating files with no content changes are advised to use 'p4 diff -sr | p4 -x- revert'. For example:
$ p4 diff -sr | p4 -x- revert
//depot/test/b#1 - was integrate, reverted
Let me know if this helps.
I am using the Perforce P4V client (version 2013.1/611291, dated 2013 March 20).
I attempted to Merge/Integrate from the main branch to my feature branch. It had been a long time since I had done this, so a significant number of files were added to the changelist. I then resolved conflicting files that could not be merged automatically. I then submitted the changelist. After doing that, I discovered that some of the files had remained in a messy conflicting state. Exactly why is a mystery to me, but instead of trying to fix them, I thought it would be easier to just undo the Merge/Integrate entirely and start over again.
To undo the Merge/Integrate, I used the 'back out' option. All affected files were added to the 'back out' changelist and I submitted it. My feature branch is now back where it was to start with, except obviously by now all affected files have had their revision number bumped up twice, and the history for affected files shows the integration and then the subsequent 'back out'.
The problem is that if I try the Merge/Integrate option again, this time round the number of files that Perforce wants to put into the integration changelist is now a fraction of those it originally tried to integrate. Put another way, it's not adding lots of files that I know are most definitely further forward in terms of development in the main branch.
The only way I seem to be able to get around this is to use the advanced option Force integration on all revisions, disregarding revision history (-f). With this option set, it will then add for merge all files from the branch.
I suspect the problem is something to do with the fact that the files now have an integration marked in their history, and therefore Perforce is using that point as the base. The fact that the messed-up integration was 'backed out' doesn't make any difference to that.
I tried to do a rollback as well, but the same problem remains.
How can I solve this?
Edit
I have later realised that there is the following similar question:
How can I undo an Integration in Perforce, and still be able to redo it?
The files which you're trying to integrate from the main branch to your feature branch have an integration history after your first integration check-in.
When you backed out the changes, you got your feature branch's files to the state where it was before the integration, but new versions of the files were created for each of the file in that previous changelist.
The next integrate hence tries to bring in ONLY the difference in the integration path since last time.
As you've mentioned already, the only way out of this situation is to run a force integrate using the -i. You can still resolve the changes using p4 resolve -as ... and p4 resolve -am ... just like last time, and then hand resolve the remaining conflicts to perform the merge. Except that the history would show 2 extra versions of the files changed in the prior merge commit and the commit for backing it out.
If you're okay with creating a feature branch at a different location and discarding the one at your current location, you could set the starting point for the new feature branch to be the commit/changelist just before you performed the problematic integrate.
Integrate from your main branch into the new feature branch and you should have a much cleaner history this time and should have all the file changes (with history) you've made in your original feature branch as well.
Unlike other version control systems (like git for example), it is unfortunately not possible to rewrite history in perforce to make it forget about the integration history and start fresh again.
This is one of the reasons in my company, all the architects and SCMs are very much picky and reiterating their workflow advice, about strictly following integration paths between branches when performing integrations using perforce.
Problem: 2 projects shared trunk and were updating some of the same files. Now one project needs to be released, so a new branch was created from a checkpoint before the projects started.
I have a list of just my changelist numbers from the mainline. Using that I can generate a list changed files and diff output using a script with a series of 'p4 describe #' commands.
Can I reformat that output and apply it to the new branch somehow?
Response to the title: "Is it possible to create a patch using a set of changelists?"
Yes.
p4 diff2 -u //path_to_your_sources/...#cln_minus_1 //path_to_your_sources/...#cln > /tmp/cln.patch.
You can then use /tmp/cln.patch as input to the patch utility. Here, 'cln' is the submitted change list number that you want to create a patch for.
I've just spent two hours struggling with this. Using cygwin patch, I had to munge the paths until they were recognised.
In the end, the magic incantation looked like this (broken across lines):
p4 diff2 -u //depot/foo/main/...#100003 //depot/foo/main/...#100000 |
sed 's#//depot/#E:/Source/#g' |
sed '/^+++\|---/s#/#\\#g' |
patch
That is:
Use p4 diff2 to get a unified diff (-u) of part of the depot between the two revisions that I care about. The second changelist is the one before the first one I want, otherwise it's not included in the diff.
Use sed to change the //depot/ to E:/Source/, which is where my workspace lives.
Change forward slashes to double backslashes (this seems to make it work).
Pipe the results through patch.
Cygwin patch is smart enough to check files out of Perforce, but I'm not sure how to get it to do it silently. It prompts with Get file 'e:\Source\foo\whatever' from Perforce with lock?.
This is with p4 version 2010.1, a fairly recent installation of Cygwin, running on PowerShell.
Oh, and after this, patch wrote out Unix-style line endings, so I used u2d to fix those up.
Perforce will let you cherry-pick changelists for integration, which may be easier than trying to generate and apply a patch. Perforce will keep track of what revisions you've integrated where, which may make future integrations easier.
Let's assume you used to have one trunk:
//depot/mycode/trunk
And you checked in all of your changes there. You branched trunk at some point in the past to:
//depot/mycode/rel
And you have a list of changelists on trunk to merge. From a client spec that maps rel, integrate each changelist:
p4 integrate //depot/mycode/trunk/...#1234,1234 //depot/mycode/rel/...
where 1234 is the changelist number. Resolve after each integration. You may also wish to build, test, and commit your integrations at various checkpoints during your integration, if you can identify good points to do so. (Perforce can handle multiple integrations per commit, but if you make a mistake you'll need to revert to the last version checked in and redo the intermediate integrations and resolves.)
p4 describe -S -du <CL number>
is the shorter and most concise command, in my opinion.
We were working on a design, and for that we created the skeleton of the classes in our main branch. Now, we are starting to code, and for that we got a new branch. So, it would be nice if I can move all the new files in the main branch into the new branch. However, I cannot check them in yet. So, is it possible to integrate the checked out changelist? Thanks.
The Perforce support web site explains how to do this: Perforce Knowledge Base: Branching work in progress. It would be nicer if it was a single step that didn't require running eight different commands.
Since release 2013.1, the way to branch work in progress is to shelve the work and unshelve it on the branch. In detail:
Shelve your outstanding changes:
$ p4 shelve ...
Change 182535 created with 10 open file(s).
Shelving files for change 182535.
edit //info.ravenbrook.com/project/mps/master/code/arenavm.c#26
# etc.
Unshelve them on the branch (using the -b option, which maps the file name through a branch specification):
$ p4 unshelve -b mps/branch/2013-06-05/diag -s 182535
... //info.ravenbrook.com/project/mps/branch/2013-06-05/diag/code/arenavm.c - must resolve //info.ravenbrook.com/project/mps/master/code/arenavm.c#=182535 before submitting
# etc.
Resolve any merges resulting from the unshelve, using p4 resolve -as to quickly do the "safe" ones, and then doing the rest with p4 resolve as usual.
$ p4 resolve -as
//gdr-peewit/info.ravenbrook.com/project/mps/branch/2013-06-05/diag/code/arenavm.c - copy from //info.ravenbrook.com/project/mps/master/code/arenavm.c
# etc.
$ p4 resolve
No file(s) to resolve.
(The example output is from a real use case I ran just now.)
I never found a way to do that within perforce, but you can at least partially automate it.
Usually when I had to do something like that I'd check out the files in the branch I want to move things to, then use WinMerge to diff the branches and copy the changes over. Once that's done you can revert the changes in the original branch and check them in in the new branch.
It's not the best solution (no automatic checkout/add/delete of files on the new branch), but was the fastest method I came up with.
Not really.
You can of course simply open the files for edit in the new branch, and manually copy the changed files from the workspace of your main branch to the new branch's workspace. This is probably the easiest way if it just a few files.
Here are a few scripts that can be handy if a larger number of files are involved.
E.g., with the P4Shelf script you can create an archive of all your changed files, and later automatically open them in any branch with the changes restored.
Also, check out some other nifty scripts for Perforce by Jim Tilander.
To rephrase Gareth Rees' answer above in simple terms,
p4 unshelve -b target_branchspec -s changelist
:)
The easy answer is - no you can't. A quick perusal of the Perforce docs didn't come up with a ready cite for this, unfortunately, but in my experience any attempt to pull the rug out from under the Perforce server will result in your changes being lost which will leave you an unhappy camper.
Make a back up, create a new work area on the new branch, and re-apply your changes, perhaps using the diff/merge strategy outlined in Herms answer.