Skip diff dialog while using p4vc - perforce

I would like to compare two p4 files from command line without it opening diff dialogI'm using p4vc
Command: "p4vc diff fileA#1 fileB#2"
This initially opens diff dialog box asking to confirm the files and versions and when I click Diff, it then shows the differences. Is there any way to bypass or skip this intermediate step?
I know I can use other diff tools as default but would prefer to use inbuilt p4 diff tool. Is there anyway to force diff or option to not show the dialog?

You can use the p4 command line client if you want to use Perforce's built-in diff logic and don't want to see any UI:
p4 diff2 fileA#1 fileB#2

I couldn't find a better way to bypass the dialog box using p4vc. From the response I received from perforce forum https://forums.perforce.com/index.php?/topic/5990-bypass-dialog-during-p4vc-diff/, a user suggested using p4merge.
Steps:
p4 print -o fA fileA#1
p4 print -o fB fileB#2
p4merge fA fB
This will bring up the p4 diff tool for comparison. The limitation with p4merge is that it can only compare local files which requires the p4 files to be printed into local files and compare them. Network bandwidth can cause slight delays fetching the files from p4.

Related

Will the Perforce command "p4 copy" keep revision info?

dear all,
I am using the Perforce Windows x64 GUI 2014.1888424. Per my test, the answer is NO. It will use the assigned revision number.
I found the "integrate" and "branch" commands also don't keep the revision info.
Are these commands designed to behavior like this?
PS: I know that rename/move will keep the revision info.
Would you please give me any hint? Thank you very much!
You didn't describe precisely what test you did, so I'm speculating slightly, but: the Perforce integrate, copy, and merge commands do preserve the overall revision history of the file.
However, many of the commands which display file history do not display the full history by default; you have to specify additional commands to instruct the server to output the history across integrations.
For example, compare the output of
p4 filelog -i
versus
p4 filelog
or
p4 changes -i
versus
p4 changes
for your experiments.
The -i flag tells the server that you want to see the history of the file from prior to the integration or copy from its previous location. Here's how it's described in 'p4 help filelog':
The -i flag includes inherited file history. If a file was created by
branching (using 'p4 integrate'), filelog lists the revisions of the
file's ancestors up to the branch points that led to the specified
revision. File history inherited by renaming (using 'p4 move') is
always displayed regardless of whether -i is specified.
Note that, as you've observed, renaming is indeed handled differently than integ/copy/merge.
As for myself, when I am studying the history of a file, I tend to nearly always use the P4V tool and its supremely powerful Revision Graph and Time Lapse View tools. These tools know how to navigate all sorts of complex integration history, and make studying the history of a file much easier.

Is it possible to create a patch using a set of changelists?

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.

Perforce - submit only files open for branch, not files open for edit

Quite often when I'm working in a branch in Perforce, I realise I need a file I didn't branch when I initially branched.
So, I add the file to my client, run p4 integrate -b branchname, then p4 submit.
Thing that bugs me is that I then need to go through the list of files for submit, and remove all entries that are open for edit.
I can't see any option in p4 help submit, but it seems like this might be a reasonably common use case.
First do
p4 submit
Assuming your p4 editor is vi,
type this command in command mode
g/#.*edit\|#.*add\|#.*delete/d
You can choice to submit a single file on the command-line.
p4 submit <filename>
Then it won't bug you about the other files.
If you have more than one file, then maybe you should move all of the files you are currently editing onto an numbered changelist, or branch onto a numbered changelist, which will provide the separation you want.
If you're going to do this, it's much easier to manage numbered changelists from one of the GUIs.

In Perforce command line, how to diff a file reopened for add?

Suppose you open a file for branch to another place (without submitting), and then reopen it for add and make some edits. I would like to diff this edited version against its branch source in a script.
p4 diff2 is no good because one of the versions is in the client.
p4 diff is no good because it can only diff against the "corresponding" version of the file in the depot, which a branched unsubmitted file doesn't have yet.
Is there a way, or is the only option to just grab the two files and diff them using a third-party tool?
Sadly, you're on the money here, you'd need to use a third party diff tool to do this because, as you rightly pointed out, until you've submitted the initial integration to the depot, it doesn't have a copy against which to diff. If you go down this route you'd obviously not be able to access files directly in the depot though, you'd need to have both files on the client PC and specify their paths explicity.
ninesided is correct that you need to have both files on the client PC.
But there are shortcuts:
If you're using P4V, choose "Diff Against..." from the context or Tools menu. For 1st Path, choose the old location and select "Latest Revision'. For 2nd path, choose the new location and select "Workspace revision on local disk".
The work of selecting the paths can be made easier if you can get both files to appear in the same pane and Ctrl-click to multi-select. e.g. use the Workspace tree pane or open the source file for edit temporarily in order to get it listed in the Pending files pane.
P4V accomplishes this by running 'p4 print -o' on the depot file to create a temporary file on the client PC, then passing that temporary file to the diff application. If you need a textual diff, you can either configure P4V to run a textual diffing application, or run p4 print -o and diff yourself.

In Perforce, how do I get a list of checked out files?

How do I get a list of the files checked out by users (including the usernames) using P4V or P4?
I want to provide a depot location and see a list of any files under that location (including sub folders) that are checked out.
From the command line:
p4 opened -a //depot/Your/Location/...
The ... indicates that sub folders should be included.
Seeing as you also asked about P4V and only had command line answers so far, here's what you do for P4V. The "Pending" pane gets you part way to what you want. Ensure the "User" and "Workspace" filters are cleared, and you'll get a list of all files grouped by changelist and client spec. Not as clean as the straight list of files you get when using the P4 command line as suggested by Iain and Mark, but may help in some situations.
An alternative is to create a custom menu in P4V that uses one of the command line solutions suggested. For example:
Tools->Manage Custom Tools
New
Call it something e.g. Open files by user
Check the "Add to applicable context menus"
In Application field, browse to p4.exe
In Arguments, type opened -a %D (the latter takes the currently selected depot path)
Check the box to run in a console.
I'm sure you could fancy this up a bit if needed to filter the output.
You can also restrict the output of p4 opened like so:
p4 opened -C <client-spec> //depot/...
to get a list of files opened on that client-spec
p4 opened //depot/...
will give you a list of files opened by the current P4USER
In case you want to search for a particular user:
p4 opened -u the_user_name
In case you want to search for particular Changelist:
p4 opened -u the_user_name -c cl_number
I just want to point out something about about the command line arguments.
It is important to add the "/..." after the folder you want to look over because it will tell perforce to do it recursively.
So, I was trying this at the beginning :
p4 opened -a //myP4Path/dev_project
Which wasn't working until I did this:
p4 opened -a //myP4Path/dev_project/...
In p4v : try to do a rename of the top directory. You will get a warning and list of the currently checked out files with user names.

Resources