I have two branches in my local workspace. I need to take a diff between them and capture the filenames in a text file.
I looked into diff and diff2
p4 diff
gives the diff between a branch in the local client workspace and it's counterpart on the server
p4 diff2
can only be used to get the diff between two branches which are on the server.
By the way, if I do "Diff Against" on the two branches on the server through p4v client, I am able to see the list of the diff files. But I don't see anything there which would import the filesnames to a text file.
But if I try p4 diff2 through the command line on the two branches on the server, i get - protected namespace - access denied.
Any pointers will be much appreciated.
If you p4 sync both branches to the required version first, then all the files are on your disk and available to the regular diff command (not a p4 sub-command) - see the man page.
For example:
diff -qr branch1 branch2
Might give you output like:
Files branch1/newfile and branch2/newfile differ
Only in branch1: newfile2
Related
I have a workspace synced to a changelist A.
I need to test version A with a changelist D, that was committed a few commits after A to the same branch. Cherry-pick it, so to speak.
How can I do it, other than p4 diff -du and applying a patch?
If you're content with just getting the files in D (at their #D revision) while leaving everything else synced to A, this is simply:
p4 sync #D,#D
But if some of the files in D were also affected by changes B and C, this might not be acceptable, since the D revisions will also contain those changes. For a true cherry-pick, you have to open the files so you can do a set of resolves that ignore B and C before cherry-picking D. My approach to this would be:
p4 -F "%depotFile%" files #D,#D | p4 -x - edit
p4 -F "%depotFile%#<D" files #D,#D | p4 -x - sync
p4 resolve -ay
p4 sync #D,#D
p4 resolve -am
If there are merge conflicts you'll need to follow this up with an interactive p4 resolve.
Note that if you actually submit these files, you'll be rolling back B and C (at least within those specific files).
If B and C didn't affect the files in D (i.e. the files returned by p4 files #D,#D), then steps 2 and 3 will be no-ops -- the sync to #<D will just leave the files at their currently synced revisions (#A), and there will be nothing to resolve/ignore. The resolve at step 5 will then do an automatic "accept theirs" (i.e. "copy from" D) since there's no "ignored" base revision in between A and D.
Another possible option would be to do this in a new branch (which you don't necessarily need to submit at any point):
p4 integ original_branch/...#A cherry_pick/...
p4 integ original_branch/...#D,#D cherry_pick/...
p4 resolve -am
The main downside of this is that it'll entail syncing new copies of all the files when you open them for branch, but if the files aren't large/numerous enough for that to be a concern, the ergonomics of p4 integ lend themselves a bit better to this sort of thing, and it can be convenient to do things like this in a separate branch within your workspace so you can mess around freely without interfering with any other work in progress, and then discard the whole thing with a revert when you're done.
Consider the following revisions of a file:
branch -1---2---
/
/
main 100--101-102--103---104---
I am currently in my branch and the file is synced to revision 2. I know that p4 has kept the history of the file, because I used merge and not copy, and indeed the history shows revisions previous to 103 (inclusive) when I look at the history of the file and check the option "Follow branch actions".
I would like to roll it back to revision 103 or before. Is this possible?
Answers for p4v preferred, but I'll take command line statements if that's the only way to do it.
The copy command is the best way of doing this:
p4 copy main#103 branch
Another option would be to use integ -f:
p4 integ -f main#103 branch
p4 resolve -at
One benefit of copy is that if you're doing this across a bunch of files (e.g. main/...#2018/01/01 to get all of main as of Jan 1) and some of them are already identical to the rev you're copying from because they haven't changed in that time, copy will leave them alone, which makes the result less noisy.
Given a large codebase and two revisions or revsets (say, a local 'source' and a target) which may or may not share a recent parent and usually contain a large number of non-relevant file deltas;
How can diff output be generated to compare the changes only for files that are modified in the source revset itself?
(This should be the delta between the ancestry; but only for the files contained within the revset.)
Using hg diff -r target -r source shows all the changes in the ancestry, even for files not modified by the source sevision.
In addition, this should be done without any knowledge of the directory structure.
If I understand correctly, you want a diff between revs source and target, but you want to restrict it to the files that were modified in changeset source. You can do it in two steps (easily assembled into one with an alias or shell script):
List the files modified in source:
hg log -r source --template '{files}'
This just outputs a list of filenames.
Request a diff for these files:
hg diff -r target -r source $(hg log -r source --template '{files}')
Step 2 is a bash command with "command substitution" $(...), which inserts the output of step one. Other methods are possible.
From hg help diff
If only one revision is specified then that revision is compared to the working directory
i.e. you can try hg up $SOURCE; hg diff -r $TARGET
I have a situation where I'd like to diff two branches in Perforce. Normally I'd use diff2 to do a server-side diff but in this case the files on the branches are so large that the diff2 call ends up filling up /tmp on my server trying to diff them and the diff fails.
I can't bring down my server to rectify this so I'm looking at checking out the the content to disk and using diff on the command line to inspect and compare the content.
The trouble is: most of the files have RCS keywords in them that are being expanded.
I know can remove keyword expansion from a file by opening the files for edit and removing the -k attribute from the files in the process, but that seems a bit brute force. I was hoping I could just tell the p4 sync command not to expand the keywords on checkout. I can't seem to find a way to do this? Is it possible?
As a possible alternative solution, does anyone know if you can tell p4 diff2 which directory to use for temporary space when you call it? If I could tell it to use abundant NAS space instead of /tmp on the Perforce server I might be able to make it work.
I'm using 2010.x version of Perforce if that changes the answer in any way.
There's no way I know of to disable keyword expansion on sync. Here's what I would try:
1) Create a branch spec between the two sets of files
2) Run "p4 files //path/to/files/... | cut -d '#' -f 1 > tmp"
Path to files above should be the right hand side of the branch spec you created
3) p4 -x tmp diff2 -b
This tells p4 to iterate over the lines of text in 'tmp' and treat them as arguments to the command. I think /tmp on your server will get cleared in-between each file this way, preventing it from filling up.
I unfortunately don't have files large enough to test that it works, so this is entirely theoretical.
To change the temp directory that p4d uses just TEMP or TMP to a different path and restart p4d. If you're on Windows make sure to call 'p4 set -S perforce TMP=' to set variable for the Perforce service; without the -S perforce you'll just set it for the current user.
Is there any way to take complete manual control over the merge process in Mercurial?
I want to be able to choose direction of file-merge, even for files without conflicts.
Is that possible?
Turn "pre-merge" off in your merge configuration. Then everything counts as a conflict and you can pick "left" or "right" for each and every file change.
[merge-tools]
mymergetool.premerge = False
from MergeToolConfiguration on the Mercurial wiki.
Edit your configuration file this way:
[ui]
merge = kdiff3
[merge-tools]
kdiff3.premerge = false
kdiff3.args=--L1 base --L2 local --L3 other $base $local $other -o $output
By default it puts the --auto argument on kdiff3 so kdiff3 auto merges.
A merge is always performed between the working directory's parent revision and another revision, by default the other head in your repository.
If you want to merge in the other "direction" you can change which branch is in your working directory by checking out a specific revision:
hg update -r [rev]
To see which heads you have in your repository run the following command:
hg heads
Alternatively, if you're using fetch you can use the --switch-parent option to merge in the other direction:
hg fetch --switch-parent
You can't change the direction of the merge on a file-by-file basis as Mercurial works with changesets which affect a whole repository not by tracking changes on to individual files like CVS.
In case of KDiff3 it is vital to add option --qall (see http://kdiff3.sourceforge.net/doc/documentation.html). There will be an automatic merge of some conflicts without this key (like "Automatically Solve Simple Conflicts" from "Merge" menu). Thus the more proper command line is:
[ui]
merge = kdiff3
[merge-tools]
kdiff3.premerge = False
kdiff3.args=$base $local $other -o $output --L1 base --L2 local --L3 other --qall