Server version: P4D/LINUX26X86_64/2018.2/1975995 (2020/06/25)
Proxy version: P4P/LINUX26X86_64/2018.2/1975995 (2020/06/25)
Broker version: P4BROKER/LINUX26X86_64/2010.2/279478
After I sync a perforce workarea to head, I 'p4 edit' a file, then manually edit the file in my workarea using my favorite text editor. Over time, other users submit changes, so I am no longer synched to the head. And I may save and re-edit the file in my workarea. Now, I want to compare my edited version of the file to the version that I synched to (which is no longer head).
I'm OK with doing a 'p4 print' of the file (with, I'm assuming, a version specifier) in the P4 depot, then comparing my edited file with that outside of p4 commands. Using one of the p4 diff commands isn't really what I want to do because the file is an xml file for which I wrote a perl script which will compare content in an order agnostic way.
I think the missing piece here is getting a handle on the P4 version of the file that my WA is synched to so that I can p4 print it out and then compare. Not sure how to do that. I'm also open to other suggestions, but remember the comparison will eventually be done by my perl script which does simple file open commands.
Set P4DIFF to point to your perl script (which needs to take the two local files as arguments) and run p4 diff. The p4 diff command does all the work of "printing" the depot file to a local temp file, invoking the diff tool (specified by P4DIFF), and cleaning up the temp file.
Related
I use Perforce to manage a project that contains some binary files (Excel, Word and Visio diagram files).
I'd like to know the safe way to update my local version of such files from the latest version available on Perforce, without corrupting/damaging/overriding the local changes. (Local changes are made locally and not submitted to Perforce yet)
Locks don't seem to solve the problem because it helps only in concurrent submission of files.
p4 reconcile to make sure that any local changes are correctly reflected in your pending changelist(s).
p4 sync as normal. Opened files will not be overwritten by a p4 sync.
If you're following the standard Perforce workflow of always opening files for edit before you modify them (i.e. you never override the "read-only" flag on your local files), you can skip step 1 and just sync at any time without fear.
p4 resolve to handle any files that have been modified both locally and in the depot.
Note that Perforce's built-in merge logic will only handle text files, and so resolve will by default offer only a binary yours/theirs choice for binary files (at will overwrite your local changes, and ay will ignore the depot changes). If you have a merge tool that can handle your binary format, you can do:
p4 set P4MERGE=your_merge_tool
p4 resolve -t
m
to invoke your merge tool as part of the resolve process. See the documentation on the P4MERGE variable for more information how this tool will be called (you may need to wrap it in a script if it doesn't follow the base theirs yours merged calling convention): https://www.perforce.com/manuals/v17.1/cmdref/Content/CmdRef/P4MERGE.html
I am trying to find all .properties files that have been touched since a specific date (last release) so the i18n team can localize any modified/new strings. I am using the following command:
p4 changes #2015/11/01,#now //depot/cloud/sp-main/ui/....properties
However, when I run it like this, I get changes all they way back to 2013, though they do contain only changes that have modified .properties files
If I run
p4 changes //depot/cloud/sp-main/ui/....properties #2015/11/01,#now
Then I get changes since 2015/11/01 but it gives me changes that do not contain .properties files.
How can I combine the filespec with the #date?
Reference:
p4 changes
filespec
It should be
p4 changes //depot/cloud/sp-main/ui/....properties#2015/11/01,#now
The file spec contains both the file path and the revision specification. (See p4 help revisions for the latter.)
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".
what is the process to rename the files in depot without getting any conflicts?
Is there any way either in p4 or command line?
Yes, but the method depends on the version of Perforce you're running. Here's how to do it from the command line (this is copied from the output of "p4 help rename").
In release 2009.1 and higher, you can use 'p4 move' to move or
rename files. Perforce clients prior to release 2009.1 do not
support 'p4 move'. However, files in older clients can be
renamed by branching one file to another and deleting the
original file. For example:
p4 integrate fromFile toFile
p4 delete fromFile
p4 submit
For further information, see the help for the individual commands.
Note: Files renamed in this way are treated as branched files
rather than moved files in subsequent operations.
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.