This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How to find untracked files in a Perforce tree? (analogue of svn status)
I want to know what p4 command that will show me which files have changed, which files are not checked in, etc.
If you're using perforce properly, "p4 opened" is what you're looking for. It will tell you what files you have opened for change. If you want to be able to change files locally, THEN open them for edit (or delete, etc.,) then you're walking out of the usage patterns that perforce expects users to abide by and you're treading on dangerous ground.
Perforce does provide mechanisms that will allow you to detect these things - if you're going to insist on working this way. "p4 fstat" will allow you to get the expected md5sum for a file from the server. Comparing that with the local md5sum will tell you if the file has changed. You could, alternatively, compare file dates - if the modification date on your local machine does not match that given by fstat, you can be fairly certain that it has changed, but to be certain, you'd have to do the md5sum check.
In the upcoming 2012.1 release there a new command named p4 status that will do the equivalent to that as if you were using SVN.
p4 status
src/tools/this.rb - reconcile to edit //depot/stuff/src/tools/this.rb#3
src/tools/that.rb - reconcile to add //depot/stuff/src/tools/that.rb#1
src/tools/other.rb - reconcile to delete //depot/stuff/src/tools/other.rb#2
For more information, read the announcement on the Perforce Blog.
While awaiting the official 2012.1 release you have basically two options:
Do it yourself using the command line
Use P4Vs "Reconcile Offline Work"
More details can be found in the Perforce KB.
Related
I have, in perforce, a sort of 'basic working set' of files that I keep checked out (and therefore writable) when working. However, every time I commit my changes, this list gets disrupted - some things committed, others reverted - and then I have to waste time tracking down and checking out all these files again.
So, is there some way to save the list of currently checked out files, and then later check out those same files again?
I primarily use P4V, but I have P4Win and command-line Perforce available. I'd strongly prefer a GUI solution, though.
I only want to save and restore the state of which files are checked out, not the contents of those files, so shelving is not the answer
I am aware of the 'Do not submit unchanged' and 'Check out after submit' options. They are not sufficient. For instance, frequently I will have files which are programmatically generated which register as 'changed' when the only thing that is different is the 'File generated on' timestamp; I need to prevent such spurious revisions from being submitted, and I have not found any practical method of searching for and managing such files that doesn't involve the 'revert if unchanged' command.
You can do:
p4 -ztag opened | grep depotFile | cut -d ' ' -f 3 > files.txt
to save a list of files already open in your client. (If you don't have Unix utilities for Windows, you could construct this list by whatever means you want, such as running p4 opened > files.txt and manually editing files.txt in an editor.)
Once you have a list of files, you can open all of them via:
p4 -x files.txt edit
This doesn't meet your preference for a GUI-based solution, but you could create .cmd scripts to perform these actions and then double-click on them (or on shortcuts to them).
The easiest solution would be to exclude those generated files via your workspace specification, e.g., "-//depot/files/ignorablefile.sh"
They can still reside in your local workspace, but the app will not attempt to update them or add them to source control.
You said that shelving's not the answer, but that's what I would go with as the easiest solution (i.e. the one that involves the least scripting and/or fewest manual steps) for the specific question you're asking:
Shelve your pending change (let's call this change 1000).
Move your open files to a new pending change (let's call this change 1001).
Submit change 1001.
Unshelve change 1000.
Sync and resolve.
Now you have the same exact files open (the unshelve opened them) but at the head revision (the sync and resolve does that).
Now, looking past what you asked for to what might make your life easier: rather than reverting the files you don't want to submit (and having some sort of scheme to get them back later, possibly via shelving as described above), what I'd do is move them to another changelist. So instead of:
Identify "unchanged" files.
Revert unchanged files.
Submit remaining files with "reopen" option.
Reopen previously reverted files (somehow).
I'd do:
Identify "unchanged" files.
Move unchanged files to another changelist N.
Submit remaining files with "reopen" option.
Move all files from changelist N back to the default changelist.
All of those except step 1 are simple one-shot commands that you can do from any client. Personally, I'd automate steps 1+2 with a script (I'm assuming it's programmatically possible to determine whether the only diff in one of these files is the timestamp) and put it into P4Win/P4V as a "custom tool".
How can i get list of files and the differences (with color highlighting) from a changelist so that I can send it for peer review.
I tried in windows cmd p4 describe #changelist however it just shows the list of files opened in the changelist.
[Update] I could find p4 diff and it gives the differences in all the changelists in a command prompt.
I was hoping for a batch file which could input a changelist number as parameter and generate a code review which i can share over email.
sorry, I am new to perforce and don't know what to lookup so I have'nt tried anything.
I see you're trying to send changes to your peers for review, and you're interested in things like color highlighting of changes, etc.
Don't try to build a code review system from scratch, yourself.
Instead, start with a code review system that is already built; there are a number of them already out there, both free and commercial.
You can start with something like Perforce Swarm, or P4Web, or the Perforce review daemon, all of which are included with Perforce, and you can just ask your sysadmin to install them.
Or there are plenty of other fine code review tools for Perforce that you can find.
But building a tool from scratch is a big project, and you probably have many other better things to do.
p4 describe #change
Should print out the diffs of the files, in a format you can control with the -d<flags> option.
the -s option turns off those diffs.
If you want a tool to review pre-commit changes, you could use ReviewBoard which we set up a one point. post-review can take local changes and post them for review.
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.
in perforce, i have a pending list with some changed files. now i want to revert to the base, but without loosing my changes, so i want to back them up somewhere. like saving the DIFFs of each file. at a later time, i want to restore those changes and continue my work.
is this possible? if so, how?
thanks!
there is no need for external tools at all, assuming you are on a unix machine (or have a proper cygwin setup under Windows, haven't tested it.) The only caveat is that Perforce's p4 diff produces an output that is slightly incompatible with patch, therefore you need it to point to your unix diff-command. In your client-root you can do
P4DIFF=/usr/bin/diff p4 diff -du > pending-changes.patch
optional (if you want to revert the open files from the command-line, otherwise use p4v):
p4 revert `p4 opened|awk -F\# '{print $1}'`
Later you would open the files for edit (can be automated by extracting the affected files from the patchfile pending-changes.patch and then:
patch < pending-patches
Depending on your path-layout in your client-root, you have to use the -p#num option of patch to get the patch applied cleanly.
You should be able to do a shelve. It's a way of saving a changelist for future editing. The link below is a Python add-in for Perforce that implements shelve. Also, I know that Practical Perforce has a couple of ways to shelve current changes without an external script. I don't have the book in front of me but I'll try to update this question tonight when I do.
http://public.perforce.com/wiki/P4_Shelve
Linked to from P4Shelve, is P4tar which looks very useful, and does the operations on the client, rather than branching on the server.
Certainly I'll be looking into doing similar things soon.
See also this question:
Sending my changelist to someone else without checking in.
It's basically the same thing.
Create a branch of these files in some appropriate location
Check out the branch versions of the files you have edited
Copy the edited files over from the trunk and submit them
Revert the files on the trunk
Now you've got those "diffs" you wanted safely archived. When your ready to apply those changes later on, just integrate them back into the trunk.
This is what the Python script, that Brett mentioned, does. This is the way to do it manually without any special tools.
How can I figure out the state of the files in my client, I want to know if the file needs an updated, or patched, or modified etc. In CVS, I used to simply run "cvs -n -q update . > file". Later look for M,U,P,C attributes to get the current status of the file.
In perforce, "p4 sync -n" doesn't give output like "cvs -n -q update". How can I see the current status of files, in case of Perforce?
To my knowledge, there isn't a command that will give you exactly what you want. In looking what the update command does, there is no single alternative in Perforce. I think that the closest that you will come will be to use the 'p4 fstat' command and parse the output from there to get the information that you need.
You might find this page helpful.
I also found this link to a p4wrapper that claims to wrap in come CVS commands (including update) into a script. There might be others like this one around as well.
I also wanted to comment that the answer to this question is like many with Perforce when asking "how do I do...". The answer usually comes down to writing a script to take the output from perforce commands to get the results that you need. Their philosophy is to provide bare bones commands and have developers build off of the basic functionality. Love it or hate it, that's the basic model. Many good scripts can be found in the Perforce Public Depot here.
Not sure if this is what you're looking for, but the p4 diff command has a few useful options. From the usage:
-sa Opened files that are different from the revision
in the depot, or missing.
-sb Opened for integrate files that have been resolved
but have been modified after being resolved.
-sd Unopened files that are missing on the client.
-se Unopened files that are different from the revision
in the depot.
-sl Every unopened file, along with the status of
'same, 'diff', or 'missing' as compared to its
revision in the depot.
-sr Opened files that are the same as the revision in the
depot.
Full disclosure: I work for Perforce
There will be a 2 new commands "p4 status" and "p4 reconcile" in the up-coming 2012.1 release. See the following for more details:
http://www.perforce.com/blog/120126/new-20121-p4reconcile-p4status
Not quite sure what you mean. If you are talking about seeing what files need "resolving" (in perforce language) then you can use:
p4 resolve -n
See the p4 command line manual website here:
http://www.perforce.com/perforce/doc.current/manuals/cmdref/resolve.html#1040665
Also P4V has a nice feature to highlight unsubmitted and dirty files, if you use that client. Right-click on a fodler in the workspace view, and select "reconcile offline work." After a bit of processing you'll get a list of files that are out of sync with the depot.
Hope this helps.