I'm throwing away old books. The room with all the old bookshelves is getting a new life, and in the process of moving the books to the new shelves in a different room, some books… don't come along.
One such is Beautiful code
, an anthology to support Amnesty International. I bought it for one chapter, Code in motion
, in which Christopher Seiwald and Laura Wingerd elaborate on Christopher's earlier Seven pillars of pretty code (go read it, it's good).
I want to throw the book away. The other chapters are just so much filler. But I can't bring myself to throw away the figures on pages 534 and 535, those are too valuable. Must have those.
Some of the code I've written since 1992 (when my first significant contribution was accepted into an open source project) is still there, bits of it heavily used. The parts of my code that goes on working without much change shares one characteristic: It reads clearly and easily. It's well-documented, well-commented and there's hardly any nesting.
I spy a causal relationship: Truth is beauty, beauty is truth.
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. […More…]
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…]
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.
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.
For many years I was a CVS user. Now I use perforce and I'm not switching back. This page describes the things I really like about perforce.
Perforce branches the right way. In CVS and many other tools the branch is part of the file. The file src/configuration.cpp may have thirteen branches, one for each release and one for main development, and they'll have version numbers like configuration.cpp#1.12.0.1.5.
By contrast, in perforce the branches are (simplifying a little) directories. […More…]