Let's pretend that user A has a file called "Test.java" and it has:
System.out.println("Hello")
Now she changes the file to
System.out.println("How are you?")
Then she decides to change it to:
System.out.println("I'm fine")
However, she doesn't want to submit the code yet, so she shelved both files with changelist 1234 and 5678.
Now user B wants to unshelve these changelists and test them, so he types:
p4 unshelve -s 1234
p4 unshelve -s 5678
My question is: where are these files located on user B's workspace? How can he run/modify these specific changelist?
Thank you!
When user B unshelves the changeset, the unshelved files will be placed in the workspace according to user B's client-spec (which specifies how depot paths are mapped to the local client). It'd be similar to if user A submitted the changeset and user B synced.
User B's versions of the files will be overwritten (unless they're already open for edit).
Related
I have a workspace synced to a changelist A.
I need to test version A with a changelist D, that was committed a few commits after A to the same branch. Cherry-pick it, so to speak.
How can I do it, other than p4 diff -du and applying a patch?
If you're content with just getting the files in D (at their #D revision) while leaving everything else synced to A, this is simply:
p4 sync #D,#D
But if some of the files in D were also affected by changes B and C, this might not be acceptable, since the D revisions will also contain those changes. For a true cherry-pick, you have to open the files so you can do a set of resolves that ignore B and C before cherry-picking D. My approach to this would be:
p4 -F "%depotFile%" files #D,#D | p4 -x - edit
p4 -F "%depotFile%#<D" files #D,#D | p4 -x - sync
p4 resolve -ay
p4 sync #D,#D
p4 resolve -am
If there are merge conflicts you'll need to follow this up with an interactive p4 resolve.
Note that if you actually submit these files, you'll be rolling back B and C (at least within those specific files).
If B and C didn't affect the files in D (i.e. the files returned by p4 files #D,#D), then steps 2 and 3 will be no-ops -- the sync to #<D will just leave the files at their currently synced revisions (#A), and there will be nothing to resolve/ignore. The resolve at step 5 will then do an automatic "accept theirs" (i.e. "copy from" D) since there's no "ignored" base revision in between A and D.
Another possible option would be to do this in a new branch (which you don't necessarily need to submit at any point):
p4 integ original_branch/...#A cherry_pick/...
p4 integ original_branch/...#D,#D cherry_pick/...
p4 resolve -am
The main downside of this is that it'll entail syncing new copies of all the files when you open them for branch, but if the files aren't large/numerous enough for that to be a concern, the ergonomics of p4 integ lend themselves a bit better to this sort of thing, and it can be convenient to do things like this in a separate branch within your workspace so you can mess around freely without interfering with any other work in progress, and then discard the whole thing with a revert when you're done.
Consider the following revisions of a file:
branch -1---2---
/
/
main 100--101-102--103---104---
I am currently in my branch and the file is synced to revision 2. I know that p4 has kept the history of the file, because I used merge and not copy, and indeed the history shows revisions previous to 103 (inclusive) when I look at the history of the file and check the option "Follow branch actions".
I would like to roll it back to revision 103 or before. Is this possible?
Answers for p4v preferred, but I'll take command line statements if that's the only way to do it.
The copy command is the best way of doing this:
p4 copy main#103 branch
Another option would be to use integ -f:
p4 integ -f main#103 branch
p4 resolve -at
One benefit of copy is that if you're doing this across a bunch of files (e.g. main/...#2018/01/01 to get all of main as of Jan 1) and some of them are already identical to the rev you're copying from because they haven't changed in that time, copy will leave them alone, which makes the result less noisy.
I have a branch in my depot that I want to copy to a parallel location that does not currently exist in the depot. (i.e. I currently have \depot\rev6.2... and I need to create another branch at \depot\rev6.2b...) There are 2 things I would like to also happen:
First, I need the changelist history from rev6.2 to copy over to rev6.2b. When I have tried using the integrate feature, I have a new branch in the depot, but the history is blank (only 1 entry from the CL I submitted to create the branch).
Second (if possible) I would like to find a quick way so that if new changes are made in rev6.2, I can easily apply them to the rev6.2b branch as well.
I am a pretty basic P4V user (2011.1), so the more details the better. Thanks in advance for any help!!
You need to enable branch history. Click the icon I've circled in red, and select "Follow Branch Actions" in the dropdown.
Regarding your second question, if you want to bring over changes from the original branch, you can just run integrate a second time. Perforce tracks the integration history, so it knows when the branch was created, and what changes have been integrated since then (if any).
Perforce keeps all the integration history, as others already mentioned so everything from the 'rev6.2b' branch will have it's history traced to the 'rev6.2' branch. The P4V Revision Graph shows all of this history visually. On the command line the 'p4 filelog' or 'p4 filelog -i' commands, for example:
$ p4 filelog //depot/rev6.2b/...
//depot/rev6.2b/bar
... #1 change 12179 branch on 2016/02/25 by super1#super2015.2 (text) 'copy'
... ... branch from //depot/rev6.2/bar#1
//depot/rev6.2b/foo
... #1 change 12179 branch on 2016/02/25 by super1#super2015.2 (text) 'copy'
... ... branch from //depot/rev6.2/foo#1
The output shows the files in rev6.2b were branched from rev6.2 directory.
I am not sure which version and OS of the Perforce server and P4V client you are using but here is some feedback.
Regarding if new changes are made in rev6.2, to easily apply them to the rev6.2b branch also you can use a change-commit trigger to do that.
You could create a branchspec that has a view that maps all the changes from 'rev6.2' to 'rev6.2b' and then use the branch spec in the copy or integ command.
See Admin Guide: Change-commit Triggers
https://www.perforce.com/perforce/doc.current/manuals/p4sag/chapter.scripting.html#scripting.triggers.submits.commit
EXAMPLE BRANCHSPEC
Here is a view of a branch spec named 'master6.2copy'
View:
//depot/rev6.2/... //depot/rev6.2b/...
EXAMPLE
Here is *.bat file showing the content of a trigger script. (This is not an official Perforce script, just an example that can be tweaked.)
The first line below can also be instead:
p4 -p localhost:1666 -u myuser -c mywksp copy -b master6.2copy
#echo off
::
:: Example: The following change-commit trigger is an MS-DOS batch file
:: This trigger fires only after a changelist submission on a master directory
::
:: Add the following line to your triggers table:
::
:: copymaster change-commit //depot/rev6.2/... "/home/user/scripts/copyrev6-2.bat"
p4 -p localhost:1666 -u myuser -c mywksp integ -b master6.2copy
p4 -p localhost:1666 -u myuser -c mywksp resolve -at
p4 -p localhost:1666 -u myuser -c mywksp submit -d "rev6.2 copy to rev6.2b after changelist"
exit 0
Hope this helps!
How do I delete a workspace that has pending files when that workspace has already been removed from disk?
Caveats:
p4 command line only; not p4v gui
regular user access; no admin access
Scenario:
create a workspace named user_workspace on the disk in the ~/my_workspace directory
p4 edit files in workspace on the default pending changelist
remove workspace by hand (rm -rf ~/my_workspace)
workspace still exists on server with pending files
Solutions that don't work:
1: Delete workspace
Doesn't work because the workspace has files opened.
p4 client -d user_workspace
Client 'user_workspace' has files opened; use -f to force delete.
2: Delete workspace with force
Doesn't work because not admin.
p4 client -d -f user_workspace
You don't have permission for this operation.
3: Delete the pending changelist; then delete workspace (try 1)
p4 changes -c user_workspace -s pending
Only lists pending numbered changelists, does not handle the default pending changelist.
p4 -c user_workspace -d changelist_number
Not possible because there is no changelist number for the pending changelist.
4: Delete the pending changelist; then delete workspace (try 2)
Trying to do a p4 revert on a directory that does not exist anymore gives a strange error.
p4 revert ~/my_workspace
/home/user/my_workspace - must refer to client 'user_workspace'.
p4 -c user_workspace revert ~/my_workspace
/home/user/my_workspace - must refer to client 'user_workspace'.
setenv P4CLIENT user_workspace; p4 -c user_workspace revert ~/my_workspace
/home/user/my_workspace - must refer to client 'user_workspace'.
1. Revert the pending changelist
Have to use Perforce depot notation instead of local directory notation because the local directory does not exist anymore.
p4 -c user_workspace revert -k //...
//blah/blah/blah/file#rev - was edit, reverted
2. Delete the client workspace
p4 client -d user_workspace
Client user_workspace deleted.
this will give you the pending changes on the client
p4 changes -c user_workspace
this will delete the pending change list of your choice
p4 change -d <change list number>
after that, you can delete the client using
p4 client -d user_workspace
The command line did not work for me. It kept reporting "over license quota" for any commands. I probably have something configured wrong related to that. This would mean I would have to first correct that problem and then use the above solution. However, I found another way to fix this issue using the p4v client.
The junk workspaces were old workspaces from my previous computer. Those without any files checked out I was able to right-click delete in the workspaces tab view. Those workspaces with files left checked out I was not able to remove as other are experiencing. To removes these I had to take a few extra steps.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Alternatively: Try these four step using only the p4v client *
Edit the workspace and just blank out the host field of the old workspace. In another thread I read this allows editing from any computer.
Switch to the workspace
Revert the files in the WORKSPACE view; there was no need to sync the files to my local machine
Delete the workspace after switching back to the workspaces tab.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I hope this helps someone.
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.
The rm -rf command only deleted files on your system, the workspace still exists in perforce. If you want to delete it, you have to revert the files first.
p4 revert ~/my_workspace
p4 client -d user_workspace
I am creating some build scripts that interact with Perforce and I would like to mark for delete a few files. What exactly is the P4 syntax using the command line?
p4 delete filename
(output of p4 help delete)
delete -- Open an existing file to delete it from the depot
p4 delete [ -c changelist# ] [ -n ] file ...
Opens a file that currently exists in the depot for deletion.
If the file is present on the client it is removed. If a pending
changelist number is given with the -c flag the opened file is
associated with that changelist, otherwise it is associated with
the 'default' pending changelist.
Files that are deleted generally do not appear on the have list.
The -n flag displays what would be opened for delete without actually
changing any files or metadata.
Teach a man to fish:
p4 help - gets you general command
syntax
p4 help commands - lists the
commands
p4 help <command name> -
provides detailed help for a specific
command
http://www.perforce.com/perforce/doc.062/manuals/boilerplates/quickstart.html
Deleting files
To delete files from both the Perforce server and your workspace, issue the p4 delete command. For example:
p4 delete demo.txt readme.txt
The specified files are removed from your workspace and marked for deletion from the server. If you decide you don't want to delete the files after all, issue the p4 revert command. When you revert files opened for delete, Perforce restores them to your workspace.
Admitted - it takes a (small) number of steps to find the (excellent!) Perforce user guide online in the version that matches your installation and get to the chapter with the information you need.
Whenever I find myself in need of anything about the p4 command line client, I rely on the help Perforce have built into it. Accessing it could not be easier:
on the command line, enter p4
This gets you to the information Michael Burr has shown in his answer (and some more).
If you do not get a help screen right away, something is wrong with our client configuration, e.g. P4PORT is not set properly. You obviously need to fix that first.