I have a PowerShell script for nightly tests which look something like:
# Check out the result file
p4 edit result.txt
# Run tests (which write into results.txt)
RunTests
# Submit results (but only if changed from last test run)
p4 submit -f revertunchanged -d "Results from nightly tests" results.txt
This works great, except from every time results.txt is unchanged. At those times an empty changelist is left after the script is finished.
Is there any way to avoid this empty changelist?
The empty changelist is no big deal; you can just delete it if you want.
But, you might instead change your script slightly: just before you do the submit, do 'p4 revert -a results.txt'. That will revert results.txt, but only if it is unchanged.
Only run the 'p4 submit' if the 'revert -a' did not revert result.txt, because that means you have actual changes in it. (Another way to check this is to run 'p4 opened results.txt' to see if 'revert -a' left it open or not.)
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.
In Perforce P4V I have a file in a pending changelist. I want to revert the contents of the file but keep the file in the changelist. How can I do that?
I tried Perforce's revert command but that removes the file from the changelist.
The only way to accomplish this (short of copy/pasting the original contents back into this file, but that seems silly) is to revert and reopen it. Shelving, by itself, does not revert the file. The concept of "shelve and revert" is still two operations.
This is not readily possible, as other respondents noted.
If you are okay with a multi-step solution, you could
Right-click the file in the changelist and choose "diff against have revision".
In the diff window, under "Edit" choose "Edit right/left pane" (whichever side yours is
on).
Copy the contents of the original and paste them over your edited workspace version
Save the file.
Your file now has no changes, and it is checked out in the same changelist.
Using the command line, it can be done in three stages. If you are using windows I highly recommend having a unix environment, e.g. cygwin (which is the one I used.)
Assume your changelist number is XYZ and you have shelved the files in their current revision (just for the sake of it!)
Step 1: get a list of files and put them in a temp file.
p4 describe XYZ | grep \/\/ | sed -e 's/\.\.\. //'| sed 's/#.*//' > temp
Step 2: revert all the files in the changelist
p4 revert -c XYZ //...
Step 3: check out / edit the files again
cat temp | xargs p4 edit -c XYZ
I assumed all the files are in edit mode (i.e. not an already opened file or a deleted file).
PS : delete temp, if you are fussy :)
I don't believe this can be done, even from the command line, since p4 sync (even with -f) explicitly excludes operations on open files.
The feature you're looking for is shelving. This will revert the file, but keep a shelved version in the changelist, which you (or someone else on a different client) can unshelve later.
One of our team member (located in different region) has shelved changes in P4 with changelist 1234.
Now, if I want to see what files are modified snf what are the changes, how can I do this?
What is the P4 command that I should use to see the changes made by our team member?
p4 describe -S 1234 should to the trick, see the documentation on describe.
To see the file content you would unshelve the files into your workspace (assuming you have a workspace for the same project your colleague is working on).
Create a new (empty) changelist with p4 change (results in e.g. 2345), then use p4 unshelve (docu) to get the modified files to your workspace:
p4 unshelve -s 1234 -c 2345
If you don't want the modified files in your workspace any longer, you can p4 revert -c 2345 them.
Using the GUI, go to Pending and remove all filters except by user, where you will put the other developer's ID. From there you should be able to see her Changelists, including the ones having shelved files. Right click on the Shelved Files icon and select Unshelve. You will have to have a workspace active that includes the files that you are trying to unshelve.
Using UI client, press Ctrl+G. Dialog window is appears. Select Changelist in combobox and input number of changelist.
Let's assume that changelist 123456 is the shelved changelist in question. As a previous answer mentioned, the way to list the files are associated with that changelist is via the p4 describe -s <changelist> command. Like so:
$ p4 describe -s 123456
Change 123456 by john.doe#JohnsBranch on 2013/10/24 15:38:10 *pending*
[Shelving my changes for Jane.]
Fix memory corruption caused by uninitialized pointer.
Affected files ...
... //depot/branches/JohnsBranch/kernel/vm/pageutils.c#1 edit
Once you know the file(s) in question, there are a couple of ways to diff the files without a corresponding workspace. Method #1 is to use p4 print:
$ p4 print -q //depot/branches/JohnsBranch/kernel/vm/pageutils.c#1 > /tmp/old
$ p4 print -q //depot/branches/JohnsBranch/kernel/vm/pageutils.c#=123456 > /tmp/new
$ diff /tmp/old /tmp/new # Or use kdiff3, tkdiff, etc.
...
<diff output here>
The other method is to use p4 diff2:
$ p4 diff2 //depot/branches/JohnsBranch/kernel/vm/pageutils.c#1 //depot/branches/JohnsBranch/kernel/vm/pageutils.c#=123456
...
<diff output here based on Perforce server's diff algorithm>
Both methods can be easily incorporated into the scripting language of choice.
jhwist's solution is good if you want to see the files' diffs.
If you want to see just the shelved files, use p4 describe -sS 1234.
The lower case s restricts the output from including file diffs.
If you wanted to see the actual content of the files, you could use:
p4 print <file>#=<shelved_change>
The #= means to look at the shelved change, where as # means to look at the change.
If you want to see only the list of files inside a ChangeList (whether it's a shelve, pending or submitted CL), without extra data, grep the result:
p4 describe -S 12345 | grep -oP '(?=//).*(?=#)'
In P4V UI, select
Search - > Go To
then choose type of changelist (in your case 'Pending changelist'), enter changelist number and click "OK".
You may try
p4 -ztag describe <changeno>
The description contains a string called '... shelved' if it is shelved.
I have a p4 client workspace on Linux machine.
I added/edited few files in my client space and then tried to submit those changes to perforce server.
I followed the steps below but could not succeed:
p4 submit -d "test" (the same command works on a Windows machine)
when I tried it with just p4 submit then it opened a p4 submit form and then I replaced [enter description here] token with the proper description and then it works.
But I don't want to edit the p4 submit form for every p4 submit task.
How can I pass this info in from the command prompt?
Answer
-d flag support for p4 submit command was not introduced in
perforce 2006 version. so here is the workaround for this problem:
To modify the description field on pre-2006.2 release Perforce Servers, try
piping the change form in/out of a stream editor. This will create a numbered
changelist, which should then be submitted.
For example, something like:
p4 change -o | sed -e "s/<enter description here>/my desc/" | p4 change -i
Which gives the output, similar to:
Change 102 created with 3 open file(s).
This change (number 102 in this case) can then be submitted, as follows:
p4 submit -c 102
It's not just the description you need to enter, you also can edit the changelist specification which allows you to exclude files from the commit.
If you can do it on windows then perhaps there is a newer client on windows than what you're using on Linux?
From http://www.perforce.com/perforce/downloads/platform.html download the appropriate version of p4 command-line client. Then:
Replace the existing p4 executable with the new one.
Or put the new p4 exe in a directory earlier in your $PATH
Make the chmod 755 <new p4>
hash -r
p4 -V to verify you are running perforce 2009.1 client
p4 help submit
We can md5sum the p4 binary
p4 info and verify the perforce server is 2006.2 or more recent.
Step 5 should produce:
$ p4 -V
Perforce - The Fast Software Configuration Management System.
Copyright 1995-2009 Perforce Software. All rights reserved.
Rev. P4/LINUX26X86/2009.1/205670 (2009/06/29).
Step 6 should produce:
$ p4 help submit
submit -- Submit open files to the depot
p4 submit [ -r -s -f option ]
p4 submit [ -r -s -f option ] files
p4 submit [ -r -f option ] -d description
p4 submit [ -r -f option ] -d description files
p4 submit [ -r -f option ] -c changelist#
p4 submit -i [ -r -s -f option ]
'p4 submit' commits a pending changelist and its files to the depot.
With no argument 'p4 submit' attempts to submit all files in the
'default' changelist. Submit provides the user with a dialog
similar to 'p4 change' so the user can compose a changelist
description. In this dialog the user is presented with the list
of files open in changelist 'default'. Files may be deleted from
this list but they cannot be added. (Use an open command (edit,
add, delete) to add additional files to a changelist.)
If a (single) file pattern is given, only those files in
the 'default' changelist that match the pattern will be submitted.
The -c flag submits the numbered pending changelist that has been
previously created with 'p4 change' or a failed 'p4 submit'.
The -d flag allows a description to be passed into submit rather
than using a numbered changelist or engaging in a change description
dialog. This option is useful when scripting but does not allow for
jobs to be added or the default changelist to be modified.
The -f flag allows a submit option to be passed into submit which
will override the one that is set in the client. See 'p4 help client'
for valid submit options.
The -i flag causes a changelist specification (including files to be
submitted) to be read from the standard input. The user's editor
is not invoked.
The -r flag allows submitted files to remain open (on the client's
default changelist) after the submit has completed.
The -s flag extends the list of jobs to include the fix status
for each job, which becomes the job's status when the changelist
is committed. See 'p4 help change' for more notes on this option.
Before committing a changelist submit locks all associated files not
already locked. If any file cannot be locked, or if the submit
fails for any other reason the files are left open in a newly
created pending changelist.
Submit is guaranteed to be atomic. Either all files will be
updated in the depot as a unit or none will be.
Of which the important bit is:
The -d flag allows a description to be passed into submit rather
than using a numbered changelist or engaging in a change description
dialog. This option is useful when scripting but does not allow for
jobs to be added or the default changelist to be modified.
Step 7:
$ md5sum $(which p4)
bef01f66b8d3964c74a2d8992c0c900c /opt/perforce/bin/p4
Step 8:
The feature was introduced in perforce 2006.2, and it's possible that it requires a sufficiently recent server to support the operation:
#106450 (Bug #258) **
'p4 submit' now sports a '-d description' option. This allows
the user to submit files without the need for a changelist
dialog. See 'p4 help submit'.