P4 Server 2013.1/610569
I am trying to script the submission of default changelist with a Job. I understand that it is not possible to directly add a job to a pending changelist and submit it however I am open to doing things the indirect fashion. Basically the steps for me are
Move all files in the Pending changelist to a new numbered changelist
Add a given P4 Job name to this new numbered changelist
Set the textual description of the numbered changelist to be the same as the P4 Job name
Submit the given job
Can someone post me the p4 commands that need to be run for this? I tried doing this from the P4V and capture the commands at the bottom but it appears when you move files we have to list all files and I was looking for a straight-forward way of doing this.
Here's a starting place:
p4 change -o | sed 's/<enter.*>/Change to fix job000001/' >change.dat
echo 'Jobs: job000001' >> change.dat
p4 change -i < change.dat >changenumber.out
p4 submit -c `cut -f 2 -d ' ' < changenumber.out`
The first two lines construct the form data for the new changelist.
The third line creates the numbered changelist, and saves the output,
which is something like "Change 12345 saved".
The fourth line extracts that change number and gives it to 'p4 submit -c'.
Of course, I haven't done any error checking, reporting of the results to the user, etc.
As an alternative, consider this:
p4 submit -d "Change to fix job000001" | grep 'Change .* submitted' | cut -f 2 -d ' ' >change.out
p4 fix -c `cat change.out` job000001
That variant submits the change without the job attached, then associates the change with the job.
Either way, please consider using one of the Perforce scripting APIs (P4Perl, P4Ruby, P4Python, etc.) instead of this, as they are much, much easier.
Related
I have a workspace in perforce in which I made some files mark for delete. Now I want to delete that workspace forcefully.
But I don't have admin rights. How can I achieve this?
Run p4 opened to see all your opened files and run p4 revert to revert them.
Then run p4 changes -c your-client-name -s pending to see all your pending changelists. Since in the first step you reverted all your open files, these changelists will all be empty. Run p4 change -d change-number to delete each empty pending changelist.
Then you can run p4 client -d to delete your client.
Why it's only 11 clicks in P4V, through an arbitrary sequence of menu items.
Right click on the changelist
Delete shelved files
'Yes'
Right click on the changelist
Remove all jobs
Right click on the changelist
Revert files
'Revert'
Right click on the changelist
Delete pending changelist
'Yes'
Let's send Perforce to usability school.
Here's a scriptable procedure for deleting a Perforce client. Use with care: this deletes all your work in progress on the client!
Revert all changed files on this client.
p4 -c $CLIENT revert -k //...
Note the use of the -k option, which "marks the file as reverted in server metadata without altering files in the client workspace". Since we are going to delete the client later, we don't care about updating the client workspace. This speeds things up if you have many files open.
Delete all shelved files from pending changes associated with the client.
p4 changes -s shelved -c $CLIENT | cut -d' ' -f2 |
while read CHANGE; do p4 shelve -c $CHANGE -d //...; done
If you never use p4 shelve you can omit this step.
All pending changes associated with the client are now empty. Delete them.
p4 changes -s pending -c $CLIENT | cut -d' ' -f2 | p4 -b 1 -x - change -d
There are now no pending changes associated with the client. Delete the client.
p4 client -d $CLIENT
(This process ought to be much easier! In particular, there seems no good reason why we have to delete shelved files associated with a client before deleting the client. If you find yourself struggling with this, do contact Perforce support and suggest that it be made simpler.)
Here is what I did to empty my default change set, which had a lot of files checked out for edit:
p4 opened | sed 's/#.*$//g' | xargs -iF p4 revert F
This will cut off the comment part from the filename produced by p4 opened and pipe the filename to p4 revert. After that I had nothing pending and p4 changes -c my-client-name -s pending yields nothing. If you have a huge change set this will take a while.
Wrote this script called p4-delete-client for deleting a p4 client (which has changelists & other problems).
It has the following features:
automatically deletes changelists (reverts pending & deletes shelved)
fixes hostname (if differs from the one the client was created on)
unlocks the client if locked
deletes the client
deletes associated files (can be configured not to from arguments)
Note that the script relies on other scripts in the repo.
try those steps :
1.Right click on the changelist
Choose 'Change Ownership'
In the workspace box choose already existing workspace and click OK
right click on changelist and choose delete and than ok.
All the files need to be reverted before the change list can be deleted.
Two steps via p4v (version 2013.4):
Revert all files.
Right click the pending changelist, and then choose "Revert Files"
Delete the change list.
Right click the changelist, and then choose "Delete Pending Changelist 'XXXXXX'"
This just worked for me in P4V for resetting the default changelist:
Right click on the default changelist and choose "Edit Pending
Changelist 'default'"
Click the button on the bottom right "Save as numbered changelist"
Right click on the new changelist and choose "Delete changelist XXX"
You can also right click on the new changelist to revert the files for whatever you need to do, which is not available as an option on the default changelist.
I made my change successfully did a p4 change and have a numbered CL.
p4 describe -c 27701190 indicates it is pending, however p4 pending and p4 opened indicate "File(s) not opened on this client".
It's not critically important that my client be updated, but I'd like to submit this CL. (I'd also be happy with getting my client situation rectified).
What's the path to either submitting this CL or opening the files involved in this CL on my client?
You can open the files for edit after the fact (i.e., after you've changed them without telling Perforce you were going to change them). Just run the edit command and open them in the desired changelist with the -c switch:
p4 edit -c 27701190 "//depot/path to files/..."
Is there a command-line way to find the most recent changelist that affects a given workspace? This can be done in the GUI by (in the workspaces tab), right-clicking the tip of the workspace tree, then going to "Folder History", and sorting by timestamp.
Thank you much and I greatly appreciate any responses.
You can use the p4 changes command (usage).
p4 changes -t -l -c YOUR_WORKSPACE -m 1 -s submitted //depot/project/...
Almost anything that can be done in P4V is achievable via the commandline (that is one of the best things about P4 is that is commandline first, gui second).
A good answer to this depends on what you mean by "changelist that affects a given workspace". Do you mean:
Changelist that modifies a given workspace definition? (There's no such thing.)
Changelist whose contents are currently synced to the workspace? (p4 changes -m1 #workspace)
Changelist whose contents COULD be synced to the workspace? (p4 changes -m1 //workspace/... -- this is the one that corresponds to the P4V operation you describe)
I'm new to perforce, coming from a history of cvs->svn->git. I'm having a difficult time seeing a compact representation of the most recent changes impacting a set of file. For instance, if I go to a directory and type:
% p4 filelog .
It doesn't do anything useful. More interesting is
% p4 filelog *
However this shows me the change history of every file individually. I'd rather see a unified view of changes in a format showing: change number, submit message, changed files for the most recent N submits.
You can almost get this with:
p4 changes -lt [file[RevRange]...]
This will show you the changelists that affected the files in question. It doesn't show which files were affected by each change, however. You could write a script that took the output of p4 changes and used p4 describe -s to get the file listing for each changelist.
Note that p4 changes includes pending changes by default. Add -s submitted for only submitted changelists. There are other flags to narrow it down further, like -u username and -m max (to limit the number of changelists returned -- it returns newest first).
To list the files that have changed between your #start,#stop times,
p4 -c WORKSPACENAME files //Path/You/Care/About/...#2013/03/20:13:40,#2014/06/016:17:00
A question that occasionally arises is what is the best way to determine the changelist that you last synced to in Perforce. This is often needed for things like injecting the changelist number into the revision info by the automatic build system.
I recommend the opposite for automatic build systems: you should first get the latest changelist from the server using:
p4 changes -s submitted -m1
then sync to that change and record it in the revision info. The reason is as follows. Although Perforce recommends the following to determine the changelist to which the workspace is synced:
p4 changes -m1 #clientname
they note a few gotchas:
This only works if you have not submitted anything from the workspace in question.
It is also possible that a client workspace is not synced to any specific changelist.
and there's an additional gotcha they don't mention:
If the highest changelist to which the sync occured strictly deleted files from the workspace, the next-highest changelist will be reported (unless it, too, strictly deleted files).
If you must sync first and record later, Perforce recommends running the following command to determine if you've been bit by the above gotchas; it should indicate nothing was synced or removed:
p4 sync -n #changelist_number
Note that this method doesn't work if a file is added in a changelist (n-1) and then deleted in the very next changelist (n). p4 changes -m1 #clientname and p4 changes ...#have both return n-3 and p4 sync -n #n-3 will say "file(s) up-to-date."
Just to answer this myself in keeping with Jeff's suggestion of using Stackoverflow as a place to keep technical snippets....
From the command line use:
p4 changes -m1 #<clientname>
And just replace with the name of your client spec. This will produce output of the form:
Change 12345 on 2008/08/21 by joebloggs#mainline-client '....top line of description...'
Which is easily parsed to extract the changelist number.
You may try finding the maximum change number in the output of the "p4 files" command. The working directory should not contain post-sync commits, though. This is just a tad better than
p4 changes -m1 "./...#have"
as the latter seems to run on the server and may fail on big source trees due to "MaxResults" limits.
$ p4 changes -m1 "./...#have"
Request too large (over 850000); see 'p4 help maxresults'.
$ p4 -G files "./...#have" | python c:/cygwin/usr/local/bin/p4lastchange.py
Files: 266948
2427657
where p4lastchange.py is based on the code from the Using P4G.py From the Command Line presentation by J.T.Goldstone, Kodak Information Network/Ofoto, April 15, 2005.
#! /usr/bin/env python
import sys, os, marshal
if os.name == "nt":
# Disable newline translation in Windows. Other operating systems do not
# translate file contents.
import msvcrt
msvcrt.setmode( sys.stdin.fileno(), os.O_BINARY )
lastcl = 0
num = 0
try:
while 1:
dict = marshal.load(sys.stdin)
num = num + 1
for key in dict.keys():
# print "%s: %s" % (key,dict[key])
if key == "change":
cl = int(dict[key])
if cl > lastcl:
lastcl = cl
except EOFError:
pass
print "Files: %s" % num
print lastcl
p4 changes -m1 #clientname which is the "recommended" way to do it for my client takes about 10 minutes
this is what I use:
p4 cstat ...#have | grep change | awk '$3 > x { x = $3 };END { print x }'
for the same client takes 2.1 seconds
If you are using P4V you can do this graphically:
In the Dashboard tab (View->Dashboard) choose a folder and you will see a list of changelists that the folder isn't yet updated with. Note the lowest number (in the highest row).
Make sure that in the Workspace Tree you have selected the same folder as previously in the Dashboard. Then go to the History tab (View->History) and scroll down to the number noted previously. The number just below that number is the number of your current changelist.
You could also use the cstat command:
p4 help cstat
cstat -- Dump change/sync status for current client
p4 cstat [files...]
Lists changes that are needed, had or partially synced in the current
client. The output is returned in tagged format, similar to the fstat
command.
The fields that cstat displays are:
change changelist number
status 'have', 'need' or 'partial'
For a serious build (one that is being prepared for testing), explicitly specify the desired label or changelist number, sync to label, and imbed it in build artifacts.
If a changelist (or label) is not given, use p4 counter change to get the current change number, and record it. But you still need to sync everything using that change number.
I don't think you can achieve exactly what you want, because in general, an entire workspace isn't synced to a particular changelist number. One can explicitly sync some files to older revisions, and then a single changelist number is meaningless. That's why a fresh sync is required to ensure that a single changelist number accurately represents the code version.
Regarding the comments: Yes, my answer is intended for use by configuration managers preparing a build to give to QA. Our developers don't normally sync as part of a build; they do a build prior to submitting—so that they can make sure their changes don't break the build or tests. In that context, we don't bother to embed a repository label.
With your approach, you are making the assumption that your whole workspace was synced to head at the time of your last changelist submission, and that changelist included all of your open files. It's too easy to be mistaken in those assumptions, hard to detect, and horribly expensive in terms of lost time. On the other hand, solving the problem is easy, with no drawbacks. And because a changelist number can be explicitly specified, it doesn't matter what revision you need or how quickly the codebase is changing.
For the whole depot (not just your workspace/client)
p4 counter change
does the job, just telling the last changelist.
The best I've found so far is to do your sync to whatever changelist you want to build and then use changes -m1 //...#have to get the current local changelist (revision).
p4 sync #CHANGELIST_NUM
p4 changes -m1 //...#have | awk '{print $2}'
Gives you the changelist number that you can the use wherever you want. I am currently looking for a simpler way than p4 changes -m1 //...#have.
I am not sure if you got the answer you needed but I had a similar problem. The goal was to write in our logger the specific version of the project. The problem was that while we are making our own makefile, the overall build system is controlled by our configuration management. This means that all the solutions which say "sync to something then do something" don't really work and I didn't want to manually change the version whenever we commit (a sure source for errors).
The solution (which is actually hinted in some of the answers above) is this:
in our makefile, I do p4 changes -m1 "./...#have"
The result for this is Change change_number on date by user#client 'msg'
I simply create the message into a string which is printed by the logger (the change number is the important element but the other is also useful to quickly decide if a certain version contains changes you know you made yourself without going to perforce to check).
Hope this helps.