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.

Features git… will never have?

What else I miss:

Change numbers: Perforce's mothership issues change numbers. Sequentially increasing, fairly small numbers. Six digits sometimes, but really fairly small, since only the last 3-4 digits tend to matter at any time.

I like the change numbers. […More…]

Features git will never have, part 2

When you sync in perforce, it updates the files you're not editing to the latest revision, and leaves the ones you're editing untouched. Git fetch, by contrast, updates everything that's changed.

Perforce's behaviour requires that client state cannot be expressed as a simple change number. Some files may be synced to change 5522, others to 5525. A git tree is always at a particular change, plus a local diff.

The cost of that simplicity is that git fetch ties p4 sync and p4 merge. If you want to pull unrelated changes into your tree and there are conflicts with your current work, then you have to deal with those conflicts immediately. p4 sync is low-risk, git fetch risks interrupting your train of thought with a merge.

Features git will never have, part 1

When you open a file for writing in perforce, it checks whether anyone else is working on the same file, and tells you who, if someone is.

This is a fine feature. It warns you if there was a misunderstanding and someone else is already doing what you're about to start doing, and it warns you if someone else has forgotten to commit a change. The price for that is that the perforce server has to know who has the file open for writing, and that when you see that message x is also editing y, you have to talk to x about whether your work conflicts.

Git has nothing like a perforce server, so no place to check for such approaching conflicts.