Why i hate perforce




















This changeset will then sit around mocking you until the sun explodes or you go and delete it… delete the file that it told you you had to create and then refused to accept. There have been quite a few comments and criticisms of this article, bot on this blog and on Reddit, and what follows is a rebuttal to those so please feel free to skip it.

The comments could basically be broken into three categories, but before I go into any of them I must point you to the best damn response anyone had to that post. Thanks keithb. Perforce is not breaking for me. I believe that the Perforce server is exactly as Jeremy describes it.

My complaints lie entirely with its end user tools. I have given Perforce over two months. I have talked with a number of developers around me who have been using it for years. When I talk with experienced people the responses are either that they have no clue how to do some operation from the command line but they can in the gui, or they have a clue how to do it on the command line or gui but have absolutely no explanation for why the whack results we see.

Perforce does not employ a paradigm that is significantly different from any other centralized Source Control Manager. With that noted, I consider Distributed Source Control Managers to be a very very recent blink in the history of computing. I simply started a git repo in the same base directory as the SVN repo, and did my work in there. There are googlers who do the same thing, mostly work in git until the branch is ready for one big perforce changelist to review and commit.

Not ideal, but you can use shelves, branches or streams. Or even complement it with. Perforce is awesome, now that there is review web interface for it swarm , I'm completely happy! It was much easier to just run p4. That's not saying much. In fact the working copy can be moved to a different location or even a different machine and work can continue there. Produce a patch based on the current state of the depot that can be applied later.

This would be a perfectly good solution if it weren't such a pain to generate sensible patch files with Perforce. Having tried hard to make p4 diff generate something acceptable to patch 1 I ended up writing a Ruby script to do it. This script is available from my Perforce Scripts page. When I had to do this recently I ended up taking option 4. It did seem to work but it was far more effort than I expected.

Next time it should be easier because I've already got the script! Now read about Why I Like Perforce. This is certainly useful but doesn't solve many of the problems raised here. In particular changes can only be unshelved back to the same location in the depot albeit perhaps on a different client spec or by a different user.

This means that moving the changes to a different branch is just as painful as is creating a branch retrospectively for shelved changes. Labels: perforce , rant , version control.



0コメント

  • 1000 / 1000