![]() ![]() The login ticket will persist on your machine and the script will pick it up (provided that it's connecting with the same P4PORT and P4USER that you used to generate the ticket). ![]() If you are scripting Perforce commands that require login credentials, and you don't want your script to stop in the middle to prompt for a password, my recommendation would be to run "p4 login" as above at some point prior to running the script. If the client is able to connect to the server and your user name is correct, you will be prompted for the password. If this gives you an error message, or says that your user is unknown, check with your Perforce administrator to make sure you have the correct P4PORT and P4USER values. To verify that your connection is correct, run: p4 info Another option is to use the "-u" and "-p" flags on every command you run (e.g. You can also use "set" or "setenv" or "export" as appropriate to your shell, but with a 2014.2 or newer Perforce client (use "p4 -V" to check your version information) you can use "p4 set" as a persistent cross-platform alternative. If you're not sure what your Perforce server address and user name are, check with your sys admin. P4PORT is specified as hostname:port, with the port usually (but not always) being 1666. Using dual-VCS can often make both the local development team happier and the corporate controllers happier as their motivations for VCS are often different”.Before connecting to the server, set P4PORT (to tell the client where the server is) and P4USER (to tell the server who you are). To quote Martin Fowler’s opinions on dual VCS, “a lot of teams can benefit from this dual-VCS working style, particularly if there’s a lot of corporate ceremony enforced by their corporate VCS. You may be amazed once again by how flexible the design of Git is which makes it possible to bridge to multiple VCS! Summary You can simply verify this by typing “git branch -a”: What it does is simply invoking the p4 command line tool to download sources to local, and then clone a Git repository out of it. To ignore this file, simply add an entry to. However, since the remote repository is not Git, it’s meaningless to check in this. ![]() gitignore file to ignore files that we don’t want to check into the remote repository for each project. Login with “p4 login” and clone a Perforce project:.Here is an example almost covering daily usage: There is a detailed explanation on the usage of git-p4 in Git’s source. Detailed explanation of the difference between git-merge and git-rebase goes here. This is not something we wanna show in the remote non-git repository. Instead of using “git merge” to merge local branches, use “git rebase”įor the last one, the reason is that when you run “git merge”, Git creates an extra commit on top of the stack for the merging.Instead of using “git pull” to fetch and merge changes from remote repository to local, use “git-p4 rebase”.Instead of using “git fetch” to fetch changes from remote repository to local, use “git-p4 sync”.Instead of using “git push” to push local commits to remote repository, use “git-p4 submit”.Commandsįour things to remember when using git-p4: Windows users need to include the git-p4.bat file in the system path. Ln -s git_source_path/contrib/fast-import/git-p4 /usr/bin/git-p4 For example, here is what my settings look like: bashrc, export P4CONFIG=/path/to/your/.p4settings. p4settings file in your home directory with the global environment settings for your Perforce repository. Install the p4 command line client (use MacPort or Homebrew if you are a Mac guy :-)).There is a lengthy tutorial on Perforce’s documentation website. The git-p4 bridge requires the p4 command line client properly set up. ![]() Setting up the Perforce command line client This post is a tutorial on how to set this up. Lately I have been using the git-p4 bridge to synchronize codes between a centralized Perforce repository and a local Git repository. Git is particularly good at this aspect which provides tons of bridges to other VCS (That’s another good reason for preferring Git over Mercurial :-)). In that case, there are many successful stories of using multiple VCS: DVCS for local version control and committing to a shared centralized VCS with a DVCS-to-VCS bridge. However, the case that I run into frequently is where there is a corporate standard for a deficient VCS, but the team wish to work efficiently by using a more powerful VCS. There’s often value to use DVCS in the team. Distributed version control systems open up lots of flexibility and provide lots of efficiency in work-flow than their centralized cousins (e.g. ![]()
0 Comments
Leave a Reply. |