Does perforce track the time and date at which changes were made to changelists? For example, updating the description text, or shelving different revisions of files into the changelist? And if so, can this information be accessed using p4 command line?
p4 changes -t will include information about the creation time of the changelist, but not the update. p4 describe doesn't seem to include any flags related to time. p4 fstat can show time information about the files in a changelist, but not the changelist itself.
No, changelists are not versioned objects (not even in the spec depot, annoyingly). The only ways to track changes to changelists are to go under the covers, e.g.:
Scrape information from the journal file (this requires some understanding of Perforce's db schema)
Add triggers on each command that might update a changelist in the ways you want to track (this requires exhaustive understanding of Perforce's command API so you don't "miss" anything that you need to trigger on).
Related
How can I determine the changelist my workarea was last synced to, regardless of which options were used by tha last 'p4 sync' (-f, -k, etc....).
I don't think its 'p4 changes -m 1 #have' (that's the revision of the client, correct ?). I observed what 'p4 changes -m 1 #have was, did a sync (got some updated files), observed again and it didn't change. And I can't see any others in 'p4 help revisions' that look like this.
I don't think topic "Determining the last changelist synced to in Perforce" answers this question as it seems to solve a problem for an automatic build system (which is not what I'm doing).
Thanks in Advance for any help !
p4 changes -m1 #have should get you something similar to the right answer. Note that what that will tell you exactly is: "among all of the revisions in my workspace, and all of the associated changelist numbers, which is the highest one?" So if you synced ONE file from the latest changelist, but a bunch of other files are unsynced, you'll get the latest change even though you're not synced to it. You'll also miss changelists that consist solely of deleted files (since you don't #have those).
The p4 cstat command will give you more thorough information on a per-change basis, telling you for each change whether you've synced all, some, or none of it.
Is there a way to view all changelists that were made in the context of a stream in perforce? I am interested in a command line way.
Similar question: suppose I have a stream and its parent. Is it possible to find the changelist that is their latest common ancestor?
If you want to see not only locally made changes but also those that are included via import, the simplest way is to switch to that stream and run the query in the context of the current client:
p4 switch STREAMNAME
p4 changes //CLIENTNAME/...
Changes made locally will usually be in the depot path that matches the stream name (e.g. //stream/STREAMNAME/...), but if you use import+ this is not necessarily so (although if you use import+ the concept of changes being made within the context of a particular stream goes out the window entirely).
Finding the changelist that is the "latest common ancestor" depends what you want to use this ancestor for and what you consider to be a "common ancestor" and even what "latest" means (the word "latest" implies most recent chronologically, but that's not necessarily the same as "closest" in terms of having the most commonality). Some general approaches that might be useful:
Use the p4 istat command to see when the last merge/copy operations happened and what the latest change was that each included.
Use the p4 changes -i command on each stream to see what changelists it includes (including integrated ancestors), and diff to find the common ancestors.
Use the p4 integrate -o command to see the merge base for each file, and get the associated changelist with p4 changes or p4 files.
Thanks to Sam Stafford for pointing this out.
First use
p4 interchanges -S <child_stream_name>
This will give you a list of the changes that have not been copied up the parent branch.
To view diffs you can either use "p4 describe" on each of the changelists in the list.
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