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.
Related
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).
I am new to Perforce and want to create a automated tool to get the latest revision by itself. I have a mapping like this:
P4CLIENT: Proj_name
Worspace root direcctory: C:\...\Proj_name
Stream: Build
Now what i desire is it should get latest revision of all files from:
Build\fold1\fold2 to C:\...\Proj_name\fold1\fold2
When I just ran p4 sync command, it copied all files from Build to C:\...\Proj_name.
So please tell how to specify the folder path from where to get the latest revision. Will the command p4 sync //depot/proj1/... work for me and how does it change in my condition ?
You use the View: section of your client spec to describe which parts of the overall repository you wish to work with, and where those files should be placed on your workstation's filesystem.
In your particular case, to specify the folder path, as well as where those files should be placed, you might specify your View: as something like:
View:
//depot/Build/fold1/fold2/... //Proj_name/fold1/fold2/...
You may have considerably more complex view mappings; the view syntax is quite powerful. To learn more about view mappings, type p4 help views.
After you change your View: specification for your client, run:
p4 sync
The sync command will notice that you have changed your view mapping, and it will re-arrange the files in the root of your client on your workstation, so that they are arranged as described by your new view mapping.
If you don't wish to sync your entire client, you can specify a subset of the files which should be sync'd, by naming that subset of files using a file pattern as an argument to the sync command:
p4 sync //depot/Build/fold1/fold2/*.cpp
However, that can be quite confusing, and I recommend that, to start, you avoid using that advanced usage, and stick to performing a p4 sync with no file arguments, at least until you get more comfortable with how p4 sync is used. For one thing, when you are sync'ing different subsets of files with different file arguments, it is quite easy to get your workstation's filesystem into an un-buildable state, by getting half of the files from one changelist and half from another, which will cause you to have code that doesn't compile, etc.
So, for now:
Consider which parts of the repository you wish to work with, and where you want them to go on your workstation's filesystem
Run p4 client and describe the appropriate View: line(s) to specify those files, using the pattern-matching syntax of the View: field
Run p4 sync and Perforce will put those files on your computer as specified.
dear all,
I am using the Perforce Windows x64 GUI 2014.1888424. Per my test, the answer is NO. It will use the assigned revision number.
I found the "integrate" and "branch" commands also don't keep the revision info.
Are these commands designed to behavior like this?
PS: I know that rename/move will keep the revision info.
Would you please give me any hint? Thank you very much!
You didn't describe precisely what test you did, so I'm speculating slightly, but: the Perforce integrate, copy, and merge commands do preserve the overall revision history of the file.
However, many of the commands which display file history do not display the full history by default; you have to specify additional commands to instruct the server to output the history across integrations.
For example, compare the output of
p4 filelog -i
versus
p4 filelog
or
p4 changes -i
versus
p4 changes
for your experiments.
The -i flag tells the server that you want to see the history of the file from prior to the integration or copy from its previous location. Here's how it's described in 'p4 help filelog':
The -i flag includes inherited file history. If a file was created by
branching (using 'p4 integrate'), filelog lists the revisions of the
file's ancestors up to the branch points that led to the specified
revision. File history inherited by renaming (using 'p4 move') is
always displayed regardless of whether -i is specified.
Note that, as you've observed, renaming is indeed handled differently than integ/copy/merge.
As for myself, when I am studying the history of a file, I tend to nearly always use the P4V tool and its supremely powerful Revision Graph and Time Lapse View tools. These tools know how to navigate all sorts of complex integration history, and make studying the history of a file much easier.
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
Problem: 2 projects shared trunk and were updating some of the same files. Now one project needs to be released, so a new branch was created from a checkpoint before the projects started.
I have a list of just my changelist numbers from the mainline. Using that I can generate a list changed files and diff output using a script with a series of 'p4 describe #' commands.
Can I reformat that output and apply it to the new branch somehow?
Response to the title: "Is it possible to create a patch using a set of changelists?"
Yes.
p4 diff2 -u //path_to_your_sources/...#cln_minus_1 //path_to_your_sources/...#cln > /tmp/cln.patch.
You can then use /tmp/cln.patch as input to the patch utility. Here, 'cln' is the submitted change list number that you want to create a patch for.
I've just spent two hours struggling with this. Using cygwin patch, I had to munge the paths until they were recognised.
In the end, the magic incantation looked like this (broken across lines):
p4 diff2 -u //depot/foo/main/...#100003 //depot/foo/main/...#100000 |
sed 's#//depot/#E:/Source/#g' |
sed '/^+++\|---/s#/#\\#g' |
patch
That is:
Use p4 diff2 to get a unified diff (-u) of part of the depot between the two revisions that I care about. The second changelist is the one before the first one I want, otherwise it's not included in the diff.
Use sed to change the //depot/ to E:/Source/, which is where my workspace lives.
Change forward slashes to double backslashes (this seems to make it work).
Pipe the results through patch.
Cygwin patch is smart enough to check files out of Perforce, but I'm not sure how to get it to do it silently. It prompts with Get file 'e:\Source\foo\whatever' from Perforce with lock?.
This is with p4 version 2010.1, a fairly recent installation of Cygwin, running on PowerShell.
Oh, and after this, patch wrote out Unix-style line endings, so I used u2d to fix those up.
Perforce will let you cherry-pick changelists for integration, which may be easier than trying to generate and apply a patch. Perforce will keep track of what revisions you've integrated where, which may make future integrations easier.
Let's assume you used to have one trunk:
//depot/mycode/trunk
And you checked in all of your changes there. You branched trunk at some point in the past to:
//depot/mycode/rel
And you have a list of changelists on trunk to merge. From a client spec that maps rel, integrate each changelist:
p4 integrate //depot/mycode/trunk/...#1234,1234 //depot/mycode/rel/...
where 1234 is the changelist number. Resolve after each integration. You may also wish to build, test, and commit your integrations at various checkpoints during your integration, if you can identify good points to do so. (Perforce can handle multiple integrations per commit, but if you make a mistake you'll need to revert to the last version checked in and redo the intermediate integrations and resolves.)
p4 describe -S -du <CL number>
is the shorter and most concise command, in my opinion.