Git, after all, not perforce

The earlier posts on git and perforce sound as if I'd rather use perforce than git. True in a way. Perforce rocks. It's practically bug-free, for a start — after more than a decade of use I can only remember one bug (using one variant of p4 obliterate made p4 diff report the wrong diff).

But rocking bug-freely isn't enough. The software has to do what's needed.

p4 rename still doesn't exist after a decade on many (most?) users' wishlist. The current suggested workaround makes me ill. Refactoring and other operations involing rename are (in my opinion) absolutely required in the long run, so I think rename is deferrable but eventually vital.

The way git implements rename would suit perforce's architecture, and as far as I can tell it's good enough. Git users don't complain about it.

IPv6 support was promised to me six years ago, it's still not there, and the six year wait made me rather apprehensive.

Perforce's license scheme for open source projects is generous, but not quite good enough. One fills in a form, sends in a fifteen-page fax and a few days later Perforce issues a one-year license for the requested number of seats. Wait twelve months, rinse and repeat. The support is great, too. But every year I had the feeling that the application was considered from first principles, often by different people, and the application of the first principles didn't feel as firm and unchanging, as predictable, as I'd wish.

In other words, I expected to want the depot for twenty years, and I was never quite confident that Perforce would renew the license twenty times. So when I lost confidence that Perforce would implement a sane p4 rename, and git appeared, I think that tipped the scales for me.