Lets say a CL was submitted with large number of files. Now the entire CL was backed out due to bug in all those files. How do I now checkout all those files at once? Any easy way do this?
The best I can come up with is:
p4 -F%depotFile% files #=<backed out changelist> | xargs -n 1 p4 edit
You'll need a 13.2 client and server to use the -F flag above.
From the visual client you can manipulate the workspace settings to checkout all files after a submit...may be more helpful for future reference if you have already submitted the changelist...
At the bottom check 'Check out submitted files after submit'
Related
I'm trying to integrated about 30 changelists from my branch to parent branch and I need to cherry-pick only related CLs.
There is a file File1 that was Updated, Renamed+Moved and Deleted. There are also files File2 - File10 that were added and immediately deleted.
P4 visual client ends with an error that File1 can't be integrated because is already opened on this client.
I tried to manually integrate cherry-picked CLs in bash:
cat changelists | while read CL; do
echo "Integrating $CL: "
p4 integrate -c 123456 //depot/MyBranch/...#="${CL}" //depot/ParentBranch/...
done
This does not complain about existing files, but it does not remove files, that were added and than deleted. Resolving does not offer to remove them. They are just marked for branching.
I tried -Di, -Ds, -f, -3 options, but this was not helpful. I'm not able to remove them manually, because it is almost 200 of files and not everything is my code.
Server version: P4D/LINUX26X86_64/2015.1/1227227 (2015/08/27)
Proxy version: P4P/LINUX26X86_64/2013.3/822226 (2014/04/08)
The easiest solution is going to be to submit the first batch of integrates before proceeding. In many cases you can stack up multiple integrates into a single revision, but once the integrate operations require opening the file for different actions (branch vs integrate vs delete vs move etc) you'll get the "already opened for (action)" error and it won't be possible to continue. If you submit the already opened file, a subsequent integrate will be able to create a new revision with the appropriate action.
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".
I would like to use a command in script - which can find whether the current directory has all changes from perforce syncd.
I know if it is my workspace I can easily do p4 sync which would get all latest files. But i would not want to sync, I just want to check - that's all !
From p4 sync documentation:
-n Display the results of the sync without actually performing the sync.
P.S. You do know how to use Google, right? It's the second hit to this query.
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.
If you do a sync in perforce it can happen, very often, to do nothing even if it should. If you do a forced sync (sync -f) it will definitely sync all the files from the server blindly and this is unacceptable if you have a big project.
The question is how can you do a fast sync?
The key part to your question is "even if it should". Without fail, in all my (too) many years of experience with Perforce, users who revert to forced syncs habitually, because a normal sync does not do what they expect, are not using Perforce correctly.
You must let Perforce manage your hard disk for you - the server knows which versions of which files you have, and so a normal sync just gets what it needs. If it fails, then that is almost without exception a sign that the user is modifying, deleting, adding, renaming files outside of Perforce (e.g. in Explorer).
Sometimes you may get a system funny (i.e. PC fault, ) that causes this, so it is not necessarily the users fault. But these are very rare - hence my "habitually" qualifier above.
If you think, hand on heart, that you are not doing anything out of the ordinary, then start to look at what other processes could be tweaking these files. E.g. does you build system do something odd, and try to modify files as it builds? Do you have an open network share that perhaps someone else is inadvertently poking? Do you have a backup system that is interfering?
Hope that helps.
As mentioned by the other answers, you need to create a separate client (workspace) for every "instance" of a directory tree synced from the depot.
If you want to force-sync only those files that have changed from the depot:
p4 diff -se ... | p4 -x - sync -f
p4 diff -sd ... | p4 -x - sync -f
Warning: that will overwrite any locally changed files (in the current directory and subdirectories).
If instead you edited some files and forgot to open them for edit first, you can do this:
p4 diff -se ... | p4 -x - edit
which will open for edit any file that's different from the depot.
And this:
p4 diff -sd ... | p4 -x - delete
will open for delete any file that was locally deleted.
If you create an inconsistency, where perforce looses track of what is going on in your workspace, you should use the "Reconcile offline work..." function (in P4V).
This will run a folder diff and tell you what options you have to resolve the inconsistencies.
In general, make sure that you always check out files explicitly through perforce (open for edit). This feels strange if you are used to other systems.
I believe that the command you're looking for is p4 clean.
From: http://www.perforce.com/perforce/r14.2/manuals/cmdref/p4_clean.html
"Files present in the workspace, but missing from the depot are deleted from the workspace.
Files present in the depot, but missing from your workspace. The version of the files that have been synced from the depot are added to your workspace.
Files modified in your workspace that have not been checked in are restored to the last version synced from the depot."