Pages

2008-11-08

Using git locally, perforce centrally.

Work In Progress...

It probably comes as no surprise for people who know me that I find Perforce a bit awkward. I have suggested in an earlier post that the only reason anyone would go for Perforce is because they already have a big Perforce repository from before.

That is not to say I'm against version control. I use version control for every project that lasts for more than a few hours, for both strategical and tactical purposes I believe that it makes me about 10% more effective, mostly because it works as a project wide undo, removing the fear of making mistakes. This is, to me, the tactical purpose of version control(*). To have that benefit however, you have to commit your work frequently. If commiting you work is hard, or can have unpleasant side effects (think breaking the build on the ci server), then you'd probably just commit every time you've finished a piece of work.

By using git at your local computer, you can have almost(**) all the benefits of having a modern version control system, without having to move the entire company to another vcs. Just do "git init", "git add ." and "git commit" in your workspace and you have a local repository.

You can now commit your work as often as you like, branch out crazy ideas, and, when you've finished a piece of work, you just commit it to the central repository using standard perforce tools.

Hint: You might find it useful to let the master branch follow perforce exactly, and do your work inside a "local" branch. That way you can even use git tools for resolving conflicts before each commit.

So, what do you loose? Nothing. You still commit to the perforce repository every time you've finished a piece of work, so no significant revision histrory is going to be lost.

Disclaimer: I work at a smart, nice company, where nobody cares if you install cygwin, git or whatever, as long as it is safe, legal and doesn't hamper productivity. Installing git may not be a smart idea at every other company :)

* One of the strategic benefits is of course that you have the revision history when you wonder what went into a specific release.
**You still have to "open files for edit". :/

2 comments:

  1. I am actually using both git and perforce together at my workplace as well. You suggestion of keeping origin master in sync with p4 was extremely helpful and I've taken it even further by having a clone of the origin (and a branch on each clone) for separate large scale feature implementations and another for quick bug fixes.

    I also don't worry about "opening files for edit" until my changes are propagated back to the origin, at which point I will "reconcile offline work" in P4. And to deal with the problem of all files being read-only, when files are synced from P4: I will hit the files with a chmod and issue a "git config core.filemode false" so that a bunch of changed file modes do not pollute my "git status" list.

    ReplyDelete