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.)
Related
We are using the following P4 command for snapshot versioning.
p4 changes -m1 /path/to/files/...#have
I noticed that the above command doesn't capture CLs of deleted files if the CL is the head CL.
So it ends up having two artifacts with the same version but different files.
I was wondering how we can cover this edge case?
This is an artifact of the fact that deleted files aren't synced to the client and will therefore never be included in #have.
If possible, the best way to address this IMO is to capture the changelist at the time you sync to the head revision. Do:
p4 changes -m1 -ssubmitted /path/to/files/...
and then use that changelist to do:
p4 sync /path/to/files/...#CHANGE
Since submitted changelists are immutable (outside of edge cases like obliterate and +S files) you now have a guarantee that anyone else syncing to that same path#change will get the same set of revisions that's in your workspace.
Note that the p4 changes command will capture changelists with deleted revisions, even if those revisions are then skipped by the p4 sync!
In P4, I only want to pull file changed my client workspace from server. But When I use "p4 sync", this command get all files from server. So, How to get files changed from list revision ? with the files were existed on local and not changed, the command P4 sync do not need sync. My command is here:
p4 sync -f //depot/...#Revision
If you want to restore a file you deleted with p4 delete file, use p4 revert file, not p4 sync. p4 sync is for getting the changes that other people made to the files, not for altering the changes that you made.
There are three different reasons that the files in your workspace might differ from the current head revision in the depot:
A new revision has been submitted to the depot since the last time you synced.
You have opened the files (e.g. with p4 edit) and made changes to them that are not yet submitted.
You have modified the read-only synced files in your workspace without opening them.
(You don't say in your question which of these is the case, which is why you've gotten a couple of different answers that are based on different assumptions about your workspace state -- I'm guessing it's #3, personally, but I'll give the answer for each one so you can understand how it's "supposed" to work vs what's actually going on here.)
In case 1, a normal p4 sync command will update only the files with new revisions. If the revision you previously synced is the same as the head revision, p4 sync won't update it. This makes p4 sync very fast -- you can have a million files in your workspace, and if only one of them has changed since you last sync, only that one file is affected.
In case 2, no p4 sync command will update the files, in the interest of preserving your open changes. To submit your changes to the depot, use p4 submit; to discard them, use p4 revert. Again, only the open files are affected by these commands, so a revert operation affecting only a few files isn't slowed down by however many other files are in your workspace.
In case 3, your workspace is in an inconsistent state -- Perforce's standard workflow is that any time you modify a local file you should "open" it so that the server can track your local work (and optimize operations like sync, submit, etc, as well as alert other users who open those files simultaneously to potential conflicts). If you modify a file locally without modifying it, commands like sync will no longer work as well because the state of your client is not known to the server.
You can recover from an inconsistent state by using the p4 reconcile command (which will open all the inconsistent files so that you can either submit or revert them), or the p4 clean command (which irrevocably discards the inconsistent local changes, as if you'd done p4 reconcile immediately followed by p4 revert). These commands are significantly slower than a normal sync operation since they need to scan the entire workspace rather than only the changed files, but they are still significantly faster than a sync -f since only the changed files are actually re-transferred.
Suppose I've made some changes to a bunch of files and sent the changelist for review. The review may take up to 24 hours. During that time I might need to edit some of the files in the changelist, but when review is over, I'll need to be able to get back to the version of the file in the approved changelist. What options do I currently have to do that in Perforce?
One option that comes to mind is stashing the files and then reverting when needed, but in this way I'll lose the changes done on top of the stashed versions.
I've read about using task streams, is it something that can help me handle that situation?
I assume that the files have been shelved in the changelist for review (as opposed to emailing them off or using some other review mechanism). If so, I'd move the open files to another changelist:
p4 change
p4 reopen -c (new change) (files)
and continue working on them. The shelved versions of the files will stay in the old changelist.
If you need to go back to the old changelist, shelve your new changelist:
p4 shelve -c (new change)
and then revert your open files (they should be safe in the new shelved changelist now) and unshelve the old changelist to keep working from that point:
p4 revert (files)
p4 unshelve -s (old change)
There are lots of variations on this you could do, such as reverting and starting over from scratch rather than building your newer changes on top of the changes that are currently under review. If you do that, you'll need to merge the changes later, but Perforce will track all of that automatically and prompt you when it's time (as long as you're using Perforce commands to sync/revert/unshelve/etc -- if you start making your own backups and restoring them manually all bets are off because Perforce doesn't know what your edits are based on any more and can't guide you through the merge process intelligently).
I have made several checkins using perforce. I have no realized that all of them are unnecessary. I would like to revert all the changes for the last x revisions in the working directory, update the version number, and check in.
I am familiar with Mercurial. The way that I would it for that would be:
$ hg revert -r last_good_changeset .
$ edit version-number.txt
$ hg ci
Is there a way to do something similar in perforce?
In Perforce, a revert refers to restoring a file to the state it was in before it was checked out. What you're looking to do is back out a submitted changelist. This Perforce KB article has a few methods to do what you're trying to do, depending on your particular circumstance.
For example, if you have revisions #1 - #6 of a particular file, and you want to roll back to revision #3, you'd do this:
p4 sync myfilename#3
p4 edit myfilename
p4 sync myfilename
You're telling Perforce to get revision #3 from the depot, check it out for edit, then try to sync it back up to #head (the latest version in the depot). Since the file is checked out from an earlier revision, Perforce schedules a resolve so you need to tell it what you want to do with the file: accept the version in the depot, accept your local changes, or try to merge the two. You'll want to tell Perforce to accept the local version (or in Perforce parlance "yours"):
p4 resolve -ay myfilename
Now that it's resolved, you can submit it with:
p4 submit
If you have a series of files you want to do this with (for example, you've edited a bunch of files in a given directory and have checked them all in together several times, and you want to back out all of those), you can use changelist syntax as well. For example, if you want to roll everything back in a given directory to changelist 123, you can do this:
p4 sync //depot/some/path/*#123
p4 edit //depot/some/path/*
p4 sync //depot/some/path/*
p4 resolve -ay //depot/some/path/*
p4 submit
This will work for any revision modifier (see p4 help revisions for alternate methods of specifying the version you want).
The rollback function is specifically designed to do this. It goes back to a certain date/time or change list # and reverts all changes in the window you give it.
Simply right click on the file in question (P4V obviously) and select rollback. It will bring up this box. Not sure how to execute from command line...Ill see if I can figure it out and add that info.
Let's say I have a project under //depot/MyProject. At changelist 1001, this project took a major change in direction, changing everything about it. At changelist 2001, it got p4 deleted. The depot is now at change 3000.
I'd like to restore //depot/MyProject back to its state at changelist 1000. Specifically, I'd like the revision history to record the fact that change 3001 is an integration of change 1000 - i.e. the last version of this project before the major change.
Can Perforce do this at all? Or do I have to rename it into something like //depot/MyProjectOriginal, because //depot/MyProject is now tainted with all those deleted revisions?
(the naive attempt to p4 integrate //depot/MyProject/...#1000 //depot/MyProject/... fails with an "all revision(s) already integrated" message)
You cannot force the integration.
You have two options: you can create a branch using changelist 1000 as the base; or sync to changelist 1000, check out all files, and then submit (a.k.a rolling back).
Option 1
If you do want the history of your changes between 1001-3000 (i.e. a fresh start from changelist 1000) then this is the better option. Using P4V, create a new branchspec and then perform an integrate from your current project to the new branch at changelist 1000. This will be submitted as changelist 3001, when you compare differences between revisions, you will not see of the changes between 1001-3000.
In the P4 visualizer this will appear as a new branch creation at 1000.
Option 2
Sync to changelist 1000, check out all files, and then submit. There should not be any conflicts to resolve. This will be submitted as changelist 3001, however when you review history you will see the everything.
I hope this makes sense, any questions, please ask.
I don't believe that you can integrate files on top of one another like that. I think that you have two options.
If you are willing to move the files, you can do a
p4 integ //depot/MyProject/...#1000 //depot/MyOriginal/Project/...
and that will integrate MyProject at changelist 1000 to the new location.
If you'd like to keep the project at the same place, you can do that as well. It's really easiest in p4v - you can right click on the folder in workspace or depot view and choose "rollback...". In the subsequent dialog, you can then pick a changelist (or date, revision, etc) to roll the folder back to. In your case, I think that you would choose changelist 1000. Stick the files into a new pending changelist (I think that this is always good practice). You can then run a preveiw (to see what would happen), save the contents to a new changelist (so that you can inspect file contents before submitting), or just go for broke and pull the trigger and submit (I generally wouldn't recommend this).
HTH
Just do:
p4 copy //depot/MyProject/...#1000 //depot/MyProject/...
This also make a nice revision graph.
Though there is an accepted answer and plenty of other solutions, none of them works for me coz I need to rollback a large directory (with GBs of data)
Here is the way I used, which works fine for huge directory:
(Suggested to do in a new and clean workspace, though not strictly required)
Assuming the directory to rollback is //depot/foo/bar and you want to rollback to changelist 1234
Make sure no one is locking any files, and make sure the directory you are trying to rollback exists in your client spec
p4 copy -v //depot/foo/bar/...#1234 //depot/foo/bar/...
p4 submit
p4 copy -v is the meat of the solution. It tells Perforce server to perform virtual copy, which means Perforce copies the files but not actually in your workspace. This avoid huge data transfer for file content (when copying and when submitting). In my case, by using "rollback" in P4V (which is doing non-virtual copy), it took over an hour just for copy, and over an hour for submit for my folder. With virtual copy, whole process took me around 1 minute.
The most important thing is, it keep a sensible history. You can see your files being updated and rolled back, and all previous history exists.
use
p4 integrate -f //depot/MyProject/...#1000 //depot/MyProject/...
The -f flag means force an integration even if they have already been integrated.
From http://www.perforce.com/perforce/doc.current/manuals/cmdref/integrate.html