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.
Related
I use Perforce to manage a project that contains some binary files (Excel, Word and Visio diagram files).
I'd like to know the safe way to update my local version of such files from the latest version available on Perforce, without corrupting/damaging/overriding the local changes. (Local changes are made locally and not submitted to Perforce yet)
Locks don't seem to solve the problem because it helps only in concurrent submission of files.
p4 reconcile to make sure that any local changes are correctly reflected in your pending changelist(s).
p4 sync as normal. Opened files will not be overwritten by a p4 sync.
If you're following the standard Perforce workflow of always opening files for edit before you modify them (i.e. you never override the "read-only" flag on your local files), you can skip step 1 and just sync at any time without fear.
p4 resolve to handle any files that have been modified both locally and in the depot.
Note that Perforce's built-in merge logic will only handle text files, and so resolve will by default offer only a binary yours/theirs choice for binary files (at will overwrite your local changes, and ay will ignore the depot changes). If you have a merge tool that can handle your binary format, you can do:
p4 set P4MERGE=your_merge_tool
p4 resolve -t
m
to invoke your merge tool as part of the resolve process. See the documentation on the P4MERGE variable for more information how this tool will be called (you may need to wrap it in a script if it doesn't follow the base theirs yours merged calling convention): https://www.perforce.com/manuals/v17.1/cmdref/Content/CmdRef/P4MERGE.html
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.
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.
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
Our trunk directory contains about 100mb of code and we create tags from the trunk directory. Normally, this is not an issue because a tag takes up no space until you need to use it for something. Since branches are created from tags in SVN, how can I create a branch from a tag wtihout first checking out the tag? It appears I need to do a Tortoise Update from Windows Explorer to get the tag down to my local machine before I can use Tortoise > Branch/Tag... to create a branch from it. This seems illogical since we don't make changes to tag folders, and it requires that I check out 100mb of code, only to create a branch, and then check out another 100mb of code in the branch folder, where the changes will actually be made.
Ideally, I'd be able to create a branch directly in the repository via RepoBrowser - but I can't see an option for it there.
Am I missing something?
Creating a branch is just a matter of copying the desired directory to another location. This can be done directly in the Repo Browser.
There is nothing special that differentiates a branch from a tag as far as Subversion is concerned. It is just a convention to store them under separate parent folders, named 'branches' and 'tags' accordingly.
The only difference between tags and branches is your attitude towards them -- they are equivalent behind the scenes -- shadow copies made in the repository.
You don't even need a working copy to create a branch/tag. For example, you can use this command-line:
svn copy http://server/test/trunk http://server/test/branch -m "make branch"
(assumes you have SVN.EXE in addition to TortoiseSVN, otherwise, use Ben's answer)