I submitted a Changelist in Perforce, but I forgot to remove a couple of files from the list first. I want to undo those changes. I understand that Perforce allows me to "rollback" -- but that just submits another change to the file, cluttering my branch. This is a file I did not intend to change at all. When I go to integrate back into the baseline, this file shows up as needing to be integrated (even though it's the same as what's on the baseline).
In Clearcase, I had the ability to simply issue a "destroy" command on the specific version of the file, nuking it from the repository, as if had never been (yes, I realize this is scary from a revision control perspective - I understand the risks).
Is there an equivalent command in Perforce? Or am I trying to do something expressly forbidden?
Perforce obliterate should be a good equivalent for cleartool rmver
p4 obliterate -y file#3,5
Obliterate revisions 3, 4, and 5 of file.
If #5 was the head revision, the new head revision is now #2, and the next revision will be #3.
If #5 was not the head revision, the head revision remains unchanged.
Perforce does allow super-users to destroy revisions. Horrible, horrible idea. I don't see why you can't just rollback.
Related
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 file //depot/Project/com/company/project/SomeClass.java that is labeled with name "version-1.0.0". Suddenly I need to revert back to that label to create a bugfix release. I update to it and then make changes to the SomeClass.java.
Now this is the part I don't understand. How do I submit the fixed SomeClass.java to Perforce without overwriting any newer revision of the source tree? With Mercurial or Git I would have a branch that has the fixed source and I would just create the bugfix build from there. But now I have no idea where I should put the fixed file.
You've got essentially the same choices in Perforce as you do in those other systems, although the terminology is a bit different.
The simple solution is to make your change to SomeClass.java, and then make a new label, called "version-1.0.1", which tags the new version of SomeClass.java rather than the old one, but otherwise is identical to the version-1.0.1 label:
p4 sync //...#version-1.0.0
p4 edit SomeClass.java
p4 submit -d Fixed_that_nasty_bug
p4 label version-1.0.1
p4 labelsync -l version-1.0.1
Alternately, you can also make a branch in Perforce, and you can use your label as the basis for making that branch.
So you could do something like:
p4 integrate //depot/Project/...#version-1.0.0 //depot/rel-1.0.1/Project/...
Then you can make your change to //depot/rel-1.0.1/Project/.../SomeClass.java, and submit it back to the rel-1.0.1 branch.
If this is your first time thinking about things like development branches, release branches, etc., can I suggest having a read of http://www.perforce.com/perforce/conferences/us/2005/presentations/Wingerd.pdf or picking up a copy of Laura Wingerd's Practical Perforce and reading the chapter on "the mainline model"?
(I am a new perforce user, but have used lots of other source code control systems in the past.)
We use a change list to check-in each bug fix; the change list comment includes the bug ID therefore it is easy to track when a bug fix has been checked into a branch.
However I can’t see an easy way to find all branches a given bug fix has been merged into, or to find all bug fixes that have been merged into a given branch.
As far as I can tell perforce does not track all the branches a change list have been merged into. As I understand it, when a merge is done in perforce the history is not copied into the target branch so the only history in the target in the comment on the change list the merge was done into.
What am I missing?
Perforce tracks where revisions of a file have been integrated, but it doesn't automatically propagate check-in comments with your bug-tracking metadata.
Given a changelist on a particular branch, you can tell whether Perforce thinks the changelist has been integrated by asking Perforce to integrate the changelist. (I'm using "branch" in the more traditional source-control sense, to mean a particular branch of the source code tree, rather than in the specific Perforce sense to mean the path of integration between these two source code trees.) Let's say you've been working in //source/project/trunk/... and you have a changelist #1234 that you'd like to check whether it's been integrated into your release branch //source/project/rel/.... Create a client that maps //source/project/rel/... and execute:
$ p4 integrate -n //source/project/trunk/...#1234,1234 //source/project/rel/...
If Perforce tells you "All revision(s) already integrated.", changelist #1234 has been integrated, and that bugfix ought to be available on the release branch. If Perforce lists files that have changed, those files have not been integrated. (It's also possible for some files in a changelist to be integrated and not others, which may make for some interesting problems.)
This doesn't scale especially well -- you need to check each bugfix on each branch you care about, though it does lend itself to automation.
You can use the "unsupported" Perforce command interchanges to get a quick idea of what changelists have not been integrated from one branch into another. (In Perforce parlance, "unsupported" means something like "might not work the same in the next revision, but we think it could be useful so we'll release it anyway".) To see what changelists haven't been integrated from our example trunk to release branches, execute:
$ p4 interchanges //source/project/trunk/... //source/project/rel/...
Change 1236 on 2010/10/10 by user#client 'Fixed some bug you don't care about'
Change 1235 on 2010/10/09 by user#other_client 'Fixed some other random bug'
In this example, I haven't listed changelist #1234 because it's already been integrated into the release branch. One problem I've experienced using interchanges is it'll list every newer revision after an unintegrated change, even if the newer revisions themselves have been integrated, so if you're cherry-picking revisions for a release branch you may see changelists listed again. I use interchanges as a first pass to get a rough idea of what I need to integrate, then look at integrate to get a better idea of what's really missing.
(Perforce also supports a similar concept of "jobs", that let one attach particular fixes to particular changelists, but my organization doesn't use them so I don't know how well they work or whether they are propagated automatically on integration.)
I'm rather new to perforce, but have quite a bit of other VCS experience...
Imagine this:
You submit changes (changelist 1)
A colleague submits changes on the same branch, accidentally overwriting your changes. (changelist 2)
I tried integrating (which P4V refuses to do since it's already integrated) and looked around for a way to just generate a patch that I could apply, but couldn't find anything.
For now, I will check out the versions in question and use an external merge tool, but it would be great to know if perforce supports this somehow.
Is there a way using the perforce tools (preferably in P4V) to reapply changelist 1?
You can't reapply changelist 1, but you can reapply changelist 2.
Sync to changelist 1.
Check out the file(s). P4V will warn you that, "You do not have the latest revision of the file.", and ask you if you want to get the latest. Ignore the warning by clicking the "Don't Get Latest" button.
Now sync to the head revision (I'm assuming changelist 2 corresponds to the head revision). The file(s) will now need to be resolved, which you (or your colleague) can do, properly this time, without clobbering the changes you made in changelist 1.
Probably the easiest way is to retrieve the changes from changelist 1 (//depot/...#1,#1) and then going through the normal resolve/merge+submit song and dance.
We were working on a design, and for that we created the skeleton of the classes in our main branch. Now, we are starting to code, and for that we got a new branch. So, it would be nice if I can move all the new files in the main branch into the new branch. However, I cannot check them in yet. So, is it possible to integrate the checked out changelist? Thanks.
The Perforce support web site explains how to do this: Perforce Knowledge Base: Branching work in progress. It would be nicer if it was a single step that didn't require running eight different commands.
Since release 2013.1, the way to branch work in progress is to shelve the work and unshelve it on the branch. In detail:
Shelve your outstanding changes:
$ p4 shelve ...
Change 182535 created with 10 open file(s).
Shelving files for change 182535.
edit //info.ravenbrook.com/project/mps/master/code/arenavm.c#26
# etc.
Unshelve them on the branch (using the -b option, which maps the file name through a branch specification):
$ p4 unshelve -b mps/branch/2013-06-05/diag -s 182535
... //info.ravenbrook.com/project/mps/branch/2013-06-05/diag/code/arenavm.c - must resolve //info.ravenbrook.com/project/mps/master/code/arenavm.c#=182535 before submitting
# etc.
Resolve any merges resulting from the unshelve, using p4 resolve -as to quickly do the "safe" ones, and then doing the rest with p4 resolve as usual.
$ p4 resolve -as
//gdr-peewit/info.ravenbrook.com/project/mps/branch/2013-06-05/diag/code/arenavm.c - copy from //info.ravenbrook.com/project/mps/master/code/arenavm.c
# etc.
$ p4 resolve
No file(s) to resolve.
(The example output is from a real use case I ran just now.)
I never found a way to do that within perforce, but you can at least partially automate it.
Usually when I had to do something like that I'd check out the files in the branch I want to move things to, then use WinMerge to diff the branches and copy the changes over. Once that's done you can revert the changes in the original branch and check them in in the new branch.
It's not the best solution (no automatic checkout/add/delete of files on the new branch), but was the fastest method I came up with.
Not really.
You can of course simply open the files for edit in the new branch, and manually copy the changed files from the workspace of your main branch to the new branch's workspace. This is probably the easiest way if it just a few files.
Here are a few scripts that can be handy if a larger number of files are involved.
E.g., with the P4Shelf script you can create an archive of all your changed files, and later automatically open them in any branch with the changes restored.
Also, check out some other nifty scripts for Perforce by Jim Tilander.
To rephrase Gareth Rees' answer above in simple terms,
p4 unshelve -b target_branchspec -s changelist
:)
The easy answer is - no you can't. A quick perusal of the Perforce docs didn't come up with a ready cite for this, unfortunately, but in my experience any attempt to pull the rug out from under the Perforce server will result in your changes being lost which will leave you an unhappy camper.
Make a back up, create a new work area on the new branch, and re-apply your changes, perhaps using the diff/merge strategy outlined in Herms answer.