I have codelines Foo v1 and Foo v2 checked out from the depot, where v2 was created
from v1 by a p4 integrate command. I have some changes to Foo v1 which
are not checked in (I don't want them to be checked in) - but rather
I want them applied to Foo v2.
How do I do this using p4 shelve?
This blog from perforce suggests p4 move -f is the way to go. (Although you might have to revert the deletes) p4 move manual.
The next release (out in beta soon) will let you directly unshelve to a different branch using a branch spec.
Related
I am very new to Perforce and just started using it.
After syncing my code using $p4 sync command i started editing a few files.
$p4 edit file1
$p4 edit file2
$p4 edit file3
These files were getting added to my default changelist. For collaborating with my team i wanted to create a changelist. For creating a changelist i ran $p4 change and removed "file1" from the changelist description. Now when i run $p4 opened. It gives an output similar to this.
//depot/... /file1 edit default change (text)
//depot/... /file2 edit default 111 (text+k)
//depot/... /file3 edit default 111 (text+k)
Now i have the following questions in my mind:
Which changelist am i currently working on is it default or 111 ??
what is the meaning of (test + k)?
When i make changes to file2 and file3 it is getting synced to changelist 111 and when i make changes to file1 it gets synced to default changelist . I am highly confused how is this happening ?
Also one more thing i am confused about is if do $p4 shelve will my changes disappear and will be reapplied only when i run unshelve command for the changelist created ?? Is this similar to git stash and git stash apply ?
It will be great if someone can answer these questions in detail. Any tutorial suggestions for Perforce will also be of great help.
Thanks in advance.
My recommendation for a Perforce tutorial is the Perforce User's Guide. Here's the section on changelists:
https://www.perforce.com/perforce/r15.1/manuals/intro/chapter.working_in_perforce.html#working_in_perforce.working_with_files.changelists
Which changelist am i currently working on is it default or 111 ??
Both! Both of these are pending changelists in your workspace.
what is the meaning of (text+k)?
The thing in parentheses is the "filetype". +k is a "filetype modifier" meaning that keywords (special words like $Id$ and $Revision$ and $Author$ in this file will be automatically expanded to appropriate values when you submit.
When i make changes to file2 and file3 it is getting synced to changelist 111 and when i make changes to file1 it gets synced to default changelist . I am highly confused how is this happening ?
Nothing is getting "synced" anywhere yet -- the pending changelists are just containers that reference the different files. When you shelve or submit, then the files associated with those changelists will get sent to the server and will be accessible by other clients. Since shelve and submit are changelist-level operations, only the files in those changelists are affected -- that's the point of having different pending changelists. You have all of the pending files in your workspace, but you can split up which ones get sent to the server at which times (it's a little like pushing different branches in git, but not -- you can do this on every operation in Perforce even when you aren't branching because each file is versioned individually rather than having the entire tree versioned as one atomic blob).
Also one more thing i am confused about is if do $p4 shelve will my changes disappear and will be reapplied only when i run unshelve command for the changelist created ?? Is this similar to git stash and git stash apply ?
No, p4 shelve only syncs the shelved change on the server with the local files in your workspace -- it doesn't in itself change your workspace. The equivalent of "stashing" would be to p4 shelve and then to p4 revert to wipe out the workspace changes. shelve on its own is a little more like doing a git push to a branch -- you keep your local copy but now it's also on the server (but not part of the "master" history). (It's not exactly the same though -- to be honest if you're brand new to Perforce I'd stick to regular old "submit" in a regular old branch since that's the basic workflow. Sharing work via shelves requires a lot more manual work since each shelf is like its own little mini-branch with no versioning.)
If I use the perforce command filelog it appears to show only the history for the current branch. Is there a way to see the history for all the branches?
EDIT:
the file name looks something like:
//depot/v2/top/foo.c
//depot/v1/top/foo.c
I want to see the history for v1 & v2. Is that a branch?
If you use the -i or -h flags, the history will switch to another branch at branch or copy points respectively, but it will still be linear (just a more curvy line).
If you want a full graph, the best bet is the Revision Graph graphical tool:
https://www.perforce.com/video-tutorials/using-revision-graph
I'm getting ready to integrate our "Dev" branch into our "Testing" branch in preparation for an upcoming release.
For our last release, after the initial integration, we determined there were some changes we didn't want to release. I rolled back some files in the Testing branch, and commented out portions of other files. Many of these files haven't changed in the Dev branch, so as far as Perforce is concerned, they've already been integrated and are good-to-go.
Obviously, I could track down the changelists and un-rollback these files. I could also integrate the offending files with the "-f" option to disregard integration history.
But I was hoping to find a way to do this "automatically". I tried integrating the entire branch with "-f", resolving, and then reverting unchanged files, but this just gives the message: <filename> has pending integrations, not reverted.
Is there a way to get Perforce to revert unchanged files that are pending integration? Is there some other approach I should take?
Have you tried the following steps under 'Pending integrations not reverted'?
http://answers.perforce.com/articles/KB_Article/Reverting-Unchanged-Files
Files that are integrated and resolved but have no content or type changes will still be submitted as new revisions, EVEN IF you have 'revertunchanged' selected in your client spec, or use 'submit -f revertunchanged'. This behavior is by design, but is not obvious.
Again, if a submit would change the integration history of a file, then that file is considered changed, even if there are no content changes. In other words, updates to integration history are considered a file change, just like content, type, and attribute changes.
The command line equivalent of the 'revertunchanged' option, p4 revert -a, offers some context. From p4 help revert:
The -a flag reverts only files that are open for edit or integrate
and are unchanged or missing. Files with pending integration records
are left open. The file arguments are optional when -a is specified.
For example:
$ p4 revert -a b
//depot/test/b#1 - has pending integrations, not reverted
Users concerned about integrating files with no content changes are advised to use 'p4 diff -sr | p4 -x- revert'. For example:
$ p4 diff -sr | p4 -x- revert
//depot/test/b#1 - was integrate, reverted
Let me know if this helps.
I would like to know how to rename a branch specification (aka, a "branch mapping") in perforce. The P4V client does not allow you to edit the branch spec name.
Is it safe to just add another branch specification, copy the settings and remove the old one?
Perforce does not provide a mechanism to rename a branch specification. Perhaps they fear you may inadvertently break some scripts if you go and rename one?
Yes, it is safe to create a new one, copy the settings from the old and delete it (provided nothing is relying on a branch specification with that old name, of course).
Lack of branch spec renaming extends to all specs (users, groups, clients, labels, jobs, etc.). This is where the command line can come in handy:
p4 branch -o OLDBRANCH | sed -e "s,OLDBRANCH,NEWBRANCH," | p4 branch -i && p4 branch -d OLDBRANCH
Check this link:
http://kb.perforce.com/article/24/renaming-depot-directories
The procedure depends on your server version. For example in the 2009+ servers you use pedit and pmove to rename and keep your file history.
Yes. But you need to do an p4 integrate to get the files over. That is what p4v "copy or rename" does. Use the rename option, that also deletes the old files.
We were working on a design, and for that we created the skeleton of the classes in our main branch. Now, we are starting to code, and for that we got a new branch. So, it would be nice if I can move all the new files in the main branch into the new branch. However, I cannot check them in yet. So, is it possible to integrate the checked out changelist? Thanks.
The Perforce support web site explains how to do this: Perforce Knowledge Base: Branching work in progress. It would be nicer if it was a single step that didn't require running eight different commands.
Since release 2013.1, the way to branch work in progress is to shelve the work and unshelve it on the branch. In detail:
Shelve your outstanding changes:
$ p4 shelve ...
Change 182535 created with 10 open file(s).
Shelving files for change 182535.
edit //info.ravenbrook.com/project/mps/master/code/arenavm.c#26
# etc.
Unshelve them on the branch (using the -b option, which maps the file name through a branch specification):
$ p4 unshelve -b mps/branch/2013-06-05/diag -s 182535
... //info.ravenbrook.com/project/mps/branch/2013-06-05/diag/code/arenavm.c - must resolve //info.ravenbrook.com/project/mps/master/code/arenavm.c#=182535 before submitting
# etc.
Resolve any merges resulting from the unshelve, using p4 resolve -as to quickly do the "safe" ones, and then doing the rest with p4 resolve as usual.
$ p4 resolve -as
//gdr-peewit/info.ravenbrook.com/project/mps/branch/2013-06-05/diag/code/arenavm.c - copy from //info.ravenbrook.com/project/mps/master/code/arenavm.c
# etc.
$ p4 resolve
No file(s) to resolve.
(The example output is from a real use case I ran just now.)
I never found a way to do that within perforce, but you can at least partially automate it.
Usually when I had to do something like that I'd check out the files in the branch I want to move things to, then use WinMerge to diff the branches and copy the changes over. Once that's done you can revert the changes in the original branch and check them in in the new branch.
It's not the best solution (no automatic checkout/add/delete of files on the new branch), but was the fastest method I came up with.
Not really.
You can of course simply open the files for edit in the new branch, and manually copy the changed files from the workspace of your main branch to the new branch's workspace. This is probably the easiest way if it just a few files.
Here are a few scripts that can be handy if a larger number of files are involved.
E.g., with the P4Shelf script you can create an archive of all your changed files, and later automatically open them in any branch with the changes restored.
Also, check out some other nifty scripts for Perforce by Jim Tilander.
To rephrase Gareth Rees' answer above in simple terms,
p4 unshelve -b target_branchspec -s changelist
:)
The easy answer is - no you can't. A quick perusal of the Perforce docs didn't come up with a ready cite for this, unfortunately, but in my experience any attempt to pull the rug out from under the Perforce server will result in your changes being lost which will leave you an unhappy camper.
Make a back up, create a new work area on the new branch, and re-apply your changes, perhaps using the diff/merge strategy outlined in Herms answer.