Given a path to a directory, How can I find all the branches in perforce that use the path as a branch source (or destination)?
I think p4 integrated will give you that information.
Related
New to perforce (and stackoverflow). I'm trying determine what has changed in my local view: I want to list all the recent changes under a directory in my workspace.
Perforce documentation seems to suggest everything is file based. Is there not a simple solution that does not require either probing each file individually and recursively down the directory tree, or filtering and processing changelists (multiple projects are sharing the same depot in my case)?
Ideally, I'm looking for the SVN equivalent of "svn log -v" (i.e., no path specification).
I'm also looking for a command-line solution.
Take a look at p4 changes and the documentation.
There are some examples, which might already help you. Moreover there are some global options, which you can use to specify the client, port, etc.
You are probably looking for something like
p4 changes -m 5 -s submitted //depot/project/..., which return the last 5 submitted changelists under the given depot path.
To see the last N changes under a particular workspace directory, do:
p4 changes -m N path/...
Note that path/... can be a relative local path, an absolute local path, or an absolute depot path. This is true for almost any Perforce command that accepts a file argument -- if you can specify one file you can usually specify an arbitrary pattern like "foldername/...", and you can usually specify it in either local or depot syntax.
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.
What is the proper method to do a selective import of a large Perforce repo?
The git-p4 docs mention that you can do a -//depot/main/ignore switch to filter directories. Would this be equivalent to running a git filter-branch to remove the same directories after a clone?
Additionally, it appears Perforce provides another feature called a "client" view. I have not used Perforce before, so I am a little unfamiliar with the usage model. My current understanding is that one would use p4 somehow to setup a proper client view before running git p4 clone. Does anyone have the complete details?
A Perforce clientspec determines what parts of the Perforce repository are visible (and will be synced) to the Perforce client. The clientspec also provides a mapping from Perforce repository paths to local paths.
You can prune a Perforce client by selectively including parts of the Perforce repository. For example
//depot/main/path1/... //your-perforce-client/main/path1/...
//depot/main/path2/... //your-perforce-client/main/path2/...
will include only //depot/main/path1/ and //depot/main/path2/ and not //depot/main/path3/. As you've noted, you also can explicitly exclude paths. For example
//depot/main/path1/... //your-perforce-client/main/path1/...
-//depot/main/path1/foo/... //your-perforce-client/main/path1/foo/...
will include everything in //depot/main/path1/ except files under its foo subdirectory.
Depending on how your Perforce repository is structured and depending on what you want to include (or exclude), you potentially could tell git-p4 directly which parts of the Perforce tree you want to import:
git p4 clone --destination=/path/to/new/git/tree //depot/path1 //depot/path2
If you want to use exclusions or if you want to adjust how Perforce depot paths are mapped to local paths, you will need to add the --use-client-spec option. You can configure which Perforce client should be used by creating a .p4config file in your Git tree's parent directory containing:
P4CLIENT=YOUR_PERFORCE_CLIENT_NAME
and then setting an environment variable:
P4CONFIG=.p4config
Doing this will cause p4 to look for a .p4config file in the current directory (and then progressively search parent directories) for Perforce configuration data.
The files that will be imported will be the intersection of paths included by the Perforce clientspec and by the paths explicitly provided on the git p4 clone command-line.
(As you mentioned, git-p4 clone does allow excluding paths by prefixing them with -. However, I do not recommend doing this because that means that those paths will be excluded only on the initial import. If files in that path are touched in Perforce in the future, performing git p4 rebase/git p4 sync will pick up those changed files (unless you remember to explicitly exclude them on the command-line again). Initially importing using --use-client-spec, however, will set a flag in .git/config that allows it to be honored automatically when using git p4 rebase/git p4 sync in the future.)
One caveat is that performing a selective clone will add extra complication if someday you want to include other parts of the Perforce repository. See my answer to "Extending git-p4 clientspec after initial clone" if you need to do that.
I want to get files from Perforce without putting them into a workspace.
E.g.
I have made changes in 2 files.
file1.cs
file2.cs
Now I want to build the project using updated file1.cs, so I want to get latest files except for file1.cs.
I thought I will get another local copy of project and build it.
I'm not sure what you really want to do, but you can get the contents of a file from the depot without using a workspace definition by using "p4 print". Example:
>p4 print -o fileName.cs //depot/path/to/fileName.cs
As far as I am aware you cannot sync files from a Perforce depot without using a workspace since this is the way it tracks what version of files you have in your workspace and also where to put them on your local machine (as well as a few other things).
I'm not sure I entirely understand your problem but if what you need to do is get another copy of the file1.cs you have in the depot without removing the changes you have to it you can simply copy the changes to another location or shelve them and re-sync the file. The more complete and less dangerous solution is to create another workspace pointing to a different physical location on your machine but the same depot location.
This explains how to create a workspace if you need it:
http://www.perforce.com/perforce/doc.062/manuals/boilerplates/quickstart.html
Make sure the 'Root' path is different to that of your current workspace, you can check what your current workspaces root is by going to the workspace tab in P4V and viewing it.
Once you have created the new workspace create a new connection and select it then sync the file(s) you need.
So I want to get latest files except file1.cs
You shouldn't do that; you should update all files and resolve any conflicts with file1.cs
Consider the situation where someone else has made changes to file56.cs that relies on changes also made to file1.cs. If you take their changelist but overwrite (or do not take) their file1.cs, then your build will break.
Shelve file1.cs so you can safely revert your local change:
p4 shelve file1.cs
p4 revert file1.cs
Now you can do your build with whatever version of file1.cs you want (you can sync back to an older version or whatever).
When you're ready to return to your change:
p4 unshelve -s CHANGE
If you're in the UI you can use File->Export To... which will copy the selected file to any folder you want.
I found the workaround but not the solution.
I get another local copy of project then build the project and submit the change.
I found an easy way of doing this with git:
$ git p4 clone //depot/your/folder
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.