If I obliterate a changelist or a file revision will I still be able to sync later revisions?
I ask because perforce shows diff against the previous revision and if that gets obliterated will the later revisions come?
eg% p4 describe 400648
Differences ...
==== //releases/version.xml#135 (text) ====
4c4
< <build build="71">
---
> <build build="72">
So if I obliterate #134 or the changelist containing it, will I be able to sync #135 and later revisions ?
Yes, you will be able to sync later versions. The p4 obliterate page http://www.perforce.com/perforce/doc.current/manuals/cmdref/obliterate.html says it will only obliterate the version(s) you specify:
If you specify a single revision (for instance, p4 obliterate file#3),
only that revision of the file is obliterated. If you specify a
revision range (for instance, p4 obliterate file#3,5), only the
revisions in that range are obliterated.
This example from the same page shows that obliterated versions will no longer exist to Perforce, but later versions will:
Obliterating files in revision ranges can also change the behavior of
scripts, as revision numbers of files may "skip" obliterated
revisions. For instance, the output of p4 filelog after obliterating
revisions #2 and #3 might look like this:
... #4 change 1276 edit on 2011/04/18 by user#dev1 (binary) 'Fixed'
... #1 change 1231 add on 2011/04/12 by user#dev1 (binary) 'First try'
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!
Server version: P4D/LINUX26X86_64/2013.2/938876 (2014/09/23)
My question is about what the resulting version number of a file would be after a "p4 resolve -am". Let's say I have a workarea in which I unshelve changes to my.file resulting in my.file#8 but the workarea has my.file#10 and there are conflicts. I do a "p4 resolve -am". I'm seeing that my.file is still my.file#8. Is that correct? Is there a way to tell if this is really neither #8 or #10 but the result of the merge of the two ?
Thanks!
A resolve -am modifies the contents of your working file (the one in your workspace), but does not create a new revision until you p4 submit. It does not change the pending changelist that the file is open in, nor assign a new submitted changelist to it.
The way to see what merges have gone into the working file is the p4 resolved command.
The p4 diff command will show you the line-by-line diff between what's in your workspace and the corresponding depot version (so if you did an unshelve into an edited file followed by a merge, this will be a combination of whatever diffs are in the shelf and whatever diffs you may have introduced in your own workspace). You can also specify a version argument to p4 diff to diff against arbitrary revisions (e.g. the shelved revision, an older depot revision, etc).
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.
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.