I'm currently (and regularly) performing very large integrations (usually 50k+ files). In P4V, it is technically possible to display and manually work with those files, but it's slow and unwieldy.
Is there some way to move unresolved files to a separate CL without needing to write an application? I was taking a look at "p4 resolve -n" but I can't figure out how to use that output with p4 reopen (assuming this is even the best way of doing what I want.)
Any help would be appreciated.
You can use this:
p4 -F %localPath% resolve -n | p4 -x - reopen -c default
Explanation:
-F %localPath%: tells p4 to output paths in local format
resolve -n: means "list unresolved files without actually resolving them". (P4 Resolve)
-x -: Tells p4 we'll be working on a list of files, and '-' means that the list of files is coming from stdin (piped) (p4 Global options)
reopen -c default: reopen incoming specified files in given changelist ("default" can be replaced by an existing changelist number). (p4 reopen)
Update:
For very big changelists, sometimes the command gets stuck. You can do it in 2 steps to workaround the problem:
p4 -F %localPath% resolve –n > c:\p4_output.txt 2>c:\p4_errors.txt
p4 -x - reopen -c default < c:\p4_output.txt
Note: When reopening files that were moved, p4 reopen will only move "half" of the change (the add) and leave the delete in the previous changelist. I haven't found a solution other than moving those manually.
Something like:
p4 -F %localFile% resolve -n | p4 -x - reopen -c CHANGE
ought to do it. (Run "p4 -e resolve -n" to see the list of available variables in the output, I think localFile is the one you want.)
I had a similar problem sometime ago.
To move a Perforce changelist to another computer/workspace,
follow the steps given in the below link:
movng unresolved files/changelists
Related
Due to legal issues, we had to obliterate entire projects from our Helix/Perforce repositories.
We were partially successful, all the past versions of the files are gone, the depots are gone too.
However, the workspaces and all the associated changelists are still there (P4V > View > Submitted Changelists).
The changelists correctly show that there are no files associated with them (because we obliterated them), but the changelist descriptions are still intact and we need those deleted as well (they contain legally "important" information, so we need them gone permanently, period).
Now my question -- is there a way either to:
1) obliterate workspaces and all the changelists pertaining to obliterated depots and workspaces?
2) If not, is there a way to script this so we can clear all descriptions of changelists under the obliterated depots/workspaces? There are thousands of changelists to modify so manual work is impossible.
Thank you very much.
Ok, I studied the Helix documentation and came up with a scripted solution. In case anyone has the same problem, I'm posting my steps to solve this below:
0) This requires all of the changelists you want to delete to have all files associated with the changelists to have been obliterated beforehand. If you haven't done that, use p4 obliterate to remove the files from the depots.
1) In command prompt with admin rights, run:
p4 changes -c the-name-of-your-workspace >c:\prune.bat
2) Open the file c:\prune.bat in a text editor that has regular expressions (regex).
3) Using regex, replace all occurrences of the string "Change " with "p4 change -f -d " (without double quotes, of course).
4) Replace all strings matching " on 2.*$" with an empty string (removes the remaining portion of the line until its end). Note: The number 2 in the search regex pattern matches the first digit of years 2000-2019 and beyond. If you have changes before the year 2000, use the digit 1.
5) Inspect your batch file, it should contain something like this:
p4 change -f -d 2083
p4 change -f -d 2074
p4 change -f -d 2073
p4 change -f -d 2072
p4 change -f -d 2071
6) Run your batch from the command prompt with admin rights.
Enjoy. Hope this helps.
Here's an easy one-line solution that works on any platform:
p4 -Ztag -F "change -df %change%" changes -c CLIENT | p4 -x - run
If the idea is to get rid of all changelists where the files have been obliterated (i.e. all empty changelists), then you can leave off the -c CLIENT. The change -df command will skip changes where the files haven't been obliterated, so it's fine to just run it over all changes.
After a while of working with perforce I was left with a lot of still open change lists.
To clean up I want to get rid of a subset of them.
So here is what makes this complicate:
For a subset of the changes the host of the client has changed.
Some changes contain shelved files.
Files from the change list may be deleted or moved.
When one or more of above points are true for a change list, p4v (the visual client) will not allow you to delete the change list.
So what is an effective way of deleting these change lists?
First of all, perforce refuses to work on any change lists if the host differs in their workspace. So step one is to change the host of the workspace to the current one. This can easily be done with the visual client p4v. Open the properties of a workspace, choose edit and change the host.
Then you can use the command line to get rid of the pesky change list(s):
# to delete a changelist
CLIENT="name_of_your_client"
CHANGE="number_of_the_changelist_to_delete"
p4 -c $CLIENT shelve -c $CHANGE -d //... # Delete all shelved files from it.
p4 -c $CLIENT revert -k -c $CHANGE //... # Revert all files from changelist (only metadata).
p4 -c $CLIENT change -d $CHANGE # Finally delete the changelist.
After the last command the change list will be gone forever.
Fixing the hostname can be done from the command line like this:
client_hostname="$(p4 client -o ${CLIENT} | grep "^Host" | awk '{print $2}')"
p4 client -o ${CLIENT} | sed "/^Host:/ s=${client_hostname}=${HOSTNAME}=" | p4 client -i
Had the same problem some time ago and wrote a script (p4-delete-changelist) that overcomes all of these problems (and another one - deleting p4 fixes).
Note that the script depends on another file in the repository.
I want to design a shell script that will take the resolve decision based on the diff chunks shown by 'p4 resolve'
The current state of my script is something like -
p4 integ -b #=CL #This will open the files in my default CL.
p4 resolve #It will now resolve the files opened in my default CL one by one
Now my Problem is, with p4 resolve, I cannot redirect its output to some file and or read the diff chunks because, it shows diff chunks for one file and waits for the user input for resolve decision. I want the script to take the very obvious resolve decision.
So, is there any way to find the diff chunks for the files in my default CL? So that, I can read these diff chunks anyhow and make these obvious resolve decisions?
I wanted to do something similar; output the actual conflicts in a Jenkins job so that the information could be sent to the relevant development engineer.
I noticed the handy p4-dump-conficts script by jwd, based on that, perhaps the following is enough
echo -e "d\ns\n" | P4EDITOR=cat p4 resolve
(i.e. get p4 resolve to (d)iff and then (s)kip and use cat to output the results. This works for all 'pending' files in the workspace)
I recently had a similar need, and hacked together a solution with a shell script.
The problem, for me, was that p4 resolve wants to be interactive, but I just wanted to see the conflicts in a file.
I didn't want to run p4 resolve -f since that would mark the file as resolved in Perforce.
I just wanted to view the conflicts, maybe email them to someone else, without really doing the resolve. You can do this interactively with the (e)dit and (s)kip commands of p4 resolve, but I wanted a hands-off version.
Save this script as p4-dump-conflicts:
#!/usr/bin/env bash
function cat_to_file() {
cat "$#" > "$OUTFILE"
}
export -f cat_to_file
destFileName=$(dirname "$1")/CONFLICTS_$(basename "$1")
OUTFILE="$destFileName" P4EDITOR=cat_to_file p4 resolve "$1" <<END_INPUT
e
s
END_INPUT
If you run p4-dump-conflicts myfile, it will write out CONFLICTS_myfile, containing the conflict markers. It will leave the file un-resolved in Perforce, though.
Note: Only works for one file, as-is.
For your question in particular, you could process the CONFLICTS_xxx file however you want, then use the results of that for the final merge resolution.
Yes, you can use p4 resolve -n to print the same output as p4 resolve, without prompting for input or taking any action. From the p4 resolve docs:
-n List the files that need resolving without actually performing the resolve.
Each time we do a build, we have to record the changelist number of source files for tracking. We have different projects (under different directories) and they are synced at different changelist number. May you please show me how can we get the changelist number of a specific directory?
Also, there's p4 changes -m1 //path/to/your/project/...#have which, if run in the client workspace that synced the files for building, will give you the highest changelist number of the files in the workspace.
You can also use the short version p4 changes -m1 #have if you don't want to specify the directory.
If you are using a shell for which "#" is a comment character like bash, remember to escape it as follows: p4 changes -m1 \#have
p4 cstat //path/to/your/project...#have |grep -B1 have|tail -n2
#thegeko, this does not require high max_scanrows perforce limits
If your build system always syncs to head on the directory before building, you can use p4 changes -m 1 //path/to/your/project/... to get the head changelist number for that directory.
If you go with this method, I would suggest running the changes command before syncing, and then explicitly syncing to that changelist. That should eliminate the chance of someone checking in between the changes command and the sync command.
I use the "lazy manual way" (aka I don't know better) within the P4V client:
Use this in the "Submitted" tab filters: //yourproject/...#>have
And it will show you which CLs you haven't synched, note the oldest one.
Remove the #>have filter and see what's the CL that came before the one you just noted.
From within the directory:
p4 changes -m1 //...#have
Using just the workspace path, p4 changes -m1 /path/to/your/workspace/...#have (or cd /path/to/your/workspace; p4 changes -m1 $(pwd)/...#have) gives you the highest changelist number of the files in the workspace. This is similar to the accepted answer above from user1054341 p4 changes -m1 //your-client-name...#have, but you don't have to remember the client name.
A path to a subdirectory in the client gives you the latest changelist in that subdirectory and its children, e.g. p4 changes -m1 /path/to/your/workspace/src/module1/...#have. This can be run from any directory within the workspace.
Omitting #have shows the latest changelist checked in to the depot.
These commands must be run from a directory in the workspace.
In my case, I just want to know what changelist number is opened (not syned to) in a specific directory. For that, I do:
p4 opened -s | cut -d' ' -f5 | uniq
p4 changes -l ... shows us the list of check-ins and the description, but it doesn't show the list of files that were modified in the check-in. Is there a way to do that in one command, without the need to create a wrapper script that combines the output of another command like p4 describe or p4 file?
In Subversion, I can do this by running svn log -v.
The 'files' command can do what you're looking for. An easy way is:
p4 files //...#=<changelist>
That example will list the files modified by that changelist, under the view specified.
You can use the "describe" command to get the description of a changelist, along with the files affected.
For example, p4 describe -s <changelist> will describe the changelist, and the "-s" will prevent it from displaying file diffs.
One liner, list all changes made to a branch, with description and list of affected files, without showing the diff. Thanks to a combination of answers. Works on windows with Unix utils
p4 changes -s submitted //depot/xxx/yyy/zzz/... | grep -o "^Change [0-9]*" | cut -f2 -d" " | p4 -x- describe -s
Output:
Change 1753385 by user#clientspec on 2019/03/08 06:29:44
Changing the world
Affected files ...
... //depot/xx/yy/zz.h#6 edit
Change 1751752 by name#clientspec on 2019/03/05 15:24:00
I made a change to a file
Affected files ...
... //depot/xx/yy/zz.h#3 integrate