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.
Related
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/...
I'm a very fresh user of Perfoce, so please be patient!
I am trying to create a commit (I understand it that in Perforce it is called a changelist) of the files which have been changed. It sort of happens automatically in other VC systems, but there seems to be no easy way of doing it in p4... The problem is (maybe) that I'm not editing the files by hand, the files are generated (please don't ask me why do I have to check in the generated files...) so the whole directory tree is getting removed and then copied over with the new files. But Perforce acts as if nothing happened. In both my workspace and the depot it displays the updated files, but when someone will check them out on another machine, the files will be of the previous version.
I'm fine with doing it either through GUI or through the command line. I'd prefer the command line, because that would spare me the trouble in the long run, but it doesn't seem like it should be much hassle either way.
In other words, let's say, this is the workflow I'm used to from SVN or Git:
Run status to see what changed.
Stage / add to commit what you want to be in the next revision.
Commit and send it to the versioning server.
What I'm not able to do is the "stage" phase - because the changes are not discovered automatically.
EDIT
Ah, I think, I figured it out: reconciliation was what I needed... well, I guess if you don't marry, this word would hardly ever happen in your vocabulary :)
It appears that the proper command is reconcile. Also, as Bryan Pendleton suggested there should be status, but I must have an older version of Perforces, which doesn't have this command. This command is also available from context menu in either depot or workspace panels of Perforce graphical interface, when you click on the modified file.
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.
I've been using Tortoise SVN + Visual SVN for about a year since left the corporate world to do my own startup. There's one feature in Tortoise SVN that I've never figured out:
How can I bundle up a bunch of changes into a PATCH or DIFF file and either: A) share them with my co-founder; or B) archive them into a standalone change that I can either "apply" or "revert" on my dev box?
At my previous employer, we used an internal tool that let us build so-called DPK files that contained a set of local changes. You could add changed files to the DPK and then share it with colleagues. They could either review the changes in a Diff tool or apply all the changes from the DPK to test your change on their box. After the review was complete, you could then check in these changes. You could also have multiple DPK's applied at the same time (provided you didn't have overlapping changes).
I want to achieve the same thing with Tortoise SVN + Visual SVN in the VS2010 IDE.
My real-world scenario is that I have some extensive change pending but uncompleted on my box. I want to ZIP up these changes and store them in a DIFF file, revert the changes, move on to something else, work on that, and in a few days reapply my changes from the archived DIFF file.
Reluctantly answering my own question. This feature is available with Tortoise SVN. Basically, you make a PATCH file, distribute it or archive it, and then you apply the PATCH. The only trick is to make sure you're in the right location in the WC (Working Copy) when you do the "apply". When you apply, you'll get a popup menu to the left with a list of all files in the changelist. You can apply the patches one by one or in bulk. Seems to work great. I should have drilled into the docs more before posting this question.
Here's the text for picking the location:
"Patch files are applied to your
working copy. This should be done from
the same folder level as was used to
create the patch. If you are not sure
what this is, just look at the first
line of the patch file. For example,
if the first file being worked on was
doc/source/english/chapter1.xml and
the first line in the patch file is
Index: english/chapter1.xml then you
need to apply the patch to the
doc/source/ folder. However, provided
you are in the correct working copy,
if you pick the wrong folder level,
TortoiseSVN will notice and suggest
the correct level."
Be sure to pick the location carefully. If Tortoise SVN can't find it because you selected the wrong node in the VS file explorer, it will try to find a matching location and that might be wrong. In my tests, the Patch feature actually tried to map to a branch (!!) when I specified the wrong location.
Here's the relevant link:
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-patch.html
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.