I want to restrict files from main to be older than 04 Jan 2013. In clearcase I can accomplish this using time command:
time 04-Jan-2013.01:00:00
element * /main/LATEST
I would like to know how to do this in perforce?
The perforce sync page mentions that you can use a date:
Label or Date
Sync to a specific symbolic revision revision (either a label or date). Enter the label or date in the space provided.
That seems more appropriate that a p4 rollback, which applies changelist per changelist.
From p4 sync:
p4 sync #2011/06/24
Bring the workspace into sync with the depot as of midnight, June 24, 2011. (That is, include all changes made during June 23.)
Related
I am interested to obtain the revision number of a file given a specific date or time period in Perforce.
If I use p4 files, I find that if there are no new submissions on that time period, the comment returned when the p4 command is executed is:
no revision(s) after that date
Full example as below:
% p4 files //depot/project/file_a.c#2018/03/06,#2018/03/07
//depot/project/file_a.c#2018/03/06,#2018/03/07 - no revision(s) after that date
But the information I am looking for is the revision number of file_a.c between 2018/03/06 and 2018/03/07, regardless whether there are submission during that dates or otherwise. Something like this would be good:
//depot/project/file_a.c#31 - edit change 12345678
Am I using the right Perforce command? Thanks for the help.
It sounds like what you're really asking for is what the latest revision of the file was as of 2018/03/07:
% p4 files //depot/project/file_a.c#2018/03/07
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.
I have submitted one file in perforce, and changes submitted by other user got reverted in merge.
Changes were not conflicting.
Is their a way, I can get that user's changes back. Means revert the revert.
Also how to submit a changelist again with new changelist number?
In order to revert a file (fall back to its previous version) you simply sync the previous version and submit that again.
For a single file the procedure goes like this:
# sync file at old revision (#3 in this example)
p4 sync //depot/file#3
# mark the file for edit
p4 edit //depot/file
# make perforce aware that something has to be merged
p4 sync //depot/file
# resolve (i.e. throw away the head revision changes and save those from #3)
p4 resolve -ay
p4 submit
If you have a changelist with several files (and not only edits, but also deletes & adds) the rollback is a bit more difficult.
See also this question.
Here's a smart script for that purpose and more info.
The 2nd part of your question I did not understand.
Submitting a change again with a new changelist number doesn't make sense, since a changelist contains diffs. If it was submitted once, then the diffs are already in the depot, so you can't submit the same diffs again.
I have a perforce shelf that's CL 1000. It was shelved by someone else at some unknown CL X.
I'm at CL 2000. I'd like to sync to whatever X is and unshelf 1000 so my code is exactly the same as when it was shelved. How do I do this?
Unfortunately, there's no guarantee that their entire client workspace was synced to just one changelist when they shelved. In the extreme case, they could have synced each file at a different change number.
That said, they were probably synced to one point in time, and you can extrapolate this from the revision numbers of the files in their shelf.
$ p4 files #=1000
//depot/foo/bar.txt#3 - edit change 1000 (text)
//depot/baz/quux.c#5 - edit change 1000 (text)
The revision numbers after the filenames indicate the revision of each shelved file that the user synced before opening them for edit.
Then, you can run p4 files with each of the file paths and revisions to get change numbers:
$ p4 files //depot/foo/bar.txt#3 //depot/baz/quux.c#5
//depot/foo/bar.txt#3 - edit change 983 (text)
//depot/baz/quux.c#5 - edit change 998 (text)
Pick the largest of the change numbers from the second command, and try syncing your client to that.
Caveats to the above
Even if we assume they synced to a single point in time, the above isn't foolproof. It only tells us they synced to a change after or including 998 and before 1000.
Let's say they synced to change 999. Their client workspace might have looked like this:
$ p4 have
//depot/an/otherfile#7 - /home/user/a/an/otherfile
//depot/foo/bar.txt#3 - /home/user/a/foo/bar.txt
//depot/baz/quux.c#5 - /home/user/a/baz/quux.c
Let's further say that it was change 999 that updated otherfile to revision 7, and that change 999 only contained otherfile.
Since otherfile was never shelved, and the latest shelved revision above came from change 998, you can't conclude based on the shelf whether the client workspace was synced to change 998 or change 999.
The even bigger caveat is that this all falls apart if they synced different files to different change numbers, but usually people don't do that.
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