Thursday, October 27, 2011

meet git-p4

For some reasons, in recent works I have to use Perforce, the revision control system used by Perl core team before 2008. Unfortunately, perforce lacks of distributed features and leads to heavy branching. In this developing, these two problems often interrupted programmers with conflicts hardly to solve. Bad workflow design also makes members forget to check out before editing randomly. A git subcommand git-p4 lets you use the great tool git locally with the smooth integration to perforce server.

The steps to configure on kernel.org are currently unavailable. The official site of Perforce saved a copy. Following normal steps to write .p4config to setup p4client and install p4 and git-p4 into $PATH, $ git p4 clone //depos/path /local/path would just work. After local commit of git, $ git p4 rebase && git p4 submit works just like $ git pull --rebase && git push to remote git repository.

By the way, if you use Mercurial there is also a perforce extension can enable hg to clone perforce repository directly with a few of setup.

However, I strongly recommend perforce users migrating to modern distributed revision control system. After all, all the best companies and organizations have given Git / Mercurial a big hug, such as Github, BitBucket, Apple, Google Code, Perl, Rails, Gnome, Debian, Android and Linux Kernel. The git-p4 is a good transformer.

2012-04-26 update:
The git-p4 is now part of the git distribution and the version on github is no longer updated and doesn't work.

2 comments:

蓽路小築 said...

Please refer to this article: http://stevehanov.ca/blog/index.php?id=50

There must be a reason that why a global-wise company decides to purchase a non-free VCS.

Think more about large-scale capability.

Unknown said...

I did know that.

however, the philosophy of git doesn't recommend you host many source trees but only a project in one repository to prevent most problems of large-scale.

the actual problem is git provides a better workflow for engineers when perforce doing worse one.

at the end of this article, the author also asked the 3 advantages of git and just grumbled the huge of .git folder in a long-term projects.

large-scale or productivity, which one is more important?