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.
Related
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.
I accidentally submitted a wrong changelist to my perforce server. I then backed out that changelist using the "backout changelist" option. But, these two changes appear in the history of all those affected files that they were once deleted and then added back again.
I want to be able to delete the history from perforce server of these two changelists. Is it possible. Can it be done via some Perforce administrator command.
EDIT: I have seen p4 change -d -f which can delete a changelist but this requires to use p4 obliterate on the files which were there in the changelist. Does this mean that I have to obliterate all the files which were affected by the changelist. This doesnt seem a viable solution for me as I do not want to delete those files. Should I only obliterate those specific two revisions of the files due to the two submitted changelists?
Your perforce administrator could call p4 obliterate to completely wipe out files, revisions and history.
But I'd strongly advise not to do so. It's a perfectly normal thing to rollback files/changes and to see the history of it.
In case you still decide to use p4 obliterate make sure you call it without the "-y" option first (preview) and then (if the output of what perforce says will happen is ok) call the same command with the "-y" option (to actually perform the obliterate).
If you call p4 obliterate with a file revision (e.g. p4 obliterate //depot/dir/file#5) then only the changes and history of that revision will be removed leaving all previous revisions and history intact. You can also obliterate a revision range.
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
Is there any option to shelve files that have been once committed? I need to expose them for a codereview. I've tried to fetch old versions and shelve them to produce something like back-diff, however it doesn't work for me: although files in shelve are old one, diff in P4V thinks they're identical to new ones.
You can diff a submitted changelist against the depot at a previous state. In your history tab, (View -> History in Menu Bar), select the changelist of interest. Drag the changelist onto the previous changelist number (be sure you have the top level of your depot/workspace selected, or at least a high enough point to include all your changes). This will open up a dialog which will be a type of directory diff which will show all the changed files. Use the arrows in the toolbar to move between changed files. Use the drag and drop and drag the old file onto the new one to see the changes between the files.
With the command line you can also do this: let's pretend your changelist is 1300
p4 diff2 ...#1299 ...#1300
but this uses the text-only 'diff'.
To produce the "back-diff" you wanted, you need to do the following:
Sync the relevant files to the revision you're interested in (p4 help sync)
Check out the relevant files into a new changelist (p4 help edit)
Sync the relevant files to the head revision (p4 help sync)
Resolve the files you have checked out by accepting target (p4 help resolve)
Shelve the files (p4 help shelve)
you can now provide the shelf as a diff of the changes that were made against head.
No. The files have been committed.
You want to back out the changelist, shelve that changelist, then back out the changelist again and submit to restore the depot to the state before you submitted.
How to do this
In P4V, select the 'Submitted Changelists' tab (View > Submitted Changelists) and find the changelist. Right-click the changelist and select 'Back Out Submitted Changelist ###'. It will prompt you create a new pending changelist.
In the 'Pending Changelist' tab (View > Pending Changelists), shelve the new changelist you just created.
Repeat step 1, creating a new pending changelist.
Submit.