The following is a list of things that the world could not agree on:

  • The metric system is better than the English system we currently use (although I kind of like liquid measurements because it’s like they’re in powers of two).
  • We should drive on the right side of the road, from the left side of the car.
  • We can’t agree whether or not to have am and pm.  Here in the U.S. we tend to refer to 24-hour time as “military time”, but I believe this is the standard in much of Europe.
  • We can’t agree whether or not the day of the month, or the month itself comes first when listing the date.  Again, in the United States the military behaves differently than the civilian world, but other countries do it differently as well.
  • How to keep the music that was on a TV show in the actual TV show when it goes to DVD.  I have over dated myself here a bit, I was thinking more of Miami Vice, but it appears it was eventually released to DVD.  I never bought it, but those occasional Saturday afternoons when there’s a marathon of it on some basic cable channel, I enjoy several episodes while I procrastinate.

The things the world doesn’t agree on that annoy me, therefore making them by far the most annoying things the world does not agree on.

  • New line characters.  With the Mac’s “Unixification”, I believe we’ve moved from 3 formats to two, but WHY!?!?  I believe one standard is quite enough, and since it uses fewer characters, we shall use the Unix standard.  I’m fixing this, right now.  From here on, lines end with 0xA.  If you have old text files that wind up with extra characters, there are several things you can do.  I suggest that you CHANGE them.  Buy a copy of SlickEdit, and if you can’t figure out how to change them, one of the people in our support department will be proud to help you.
  • File system case sensitivity.  Case sensitive on UNIX, case insensitive/case preserving on Windows.  AND Mac.  And you could possibly have different file systems on UNIX that are case preserving, so that’s always a possibility.  I’ll make this decision too: case insensitive/case preserving.  OS and file system vendors, take note.  If you’re on UNIX and have separate files, one named “LS” and one as “ls”, I suggest that you CHANGE them first,  then comment on this post explaining why you would ever have done such a thing on purpose.
  • Indent levels.  Some people say 3.  Some people say 4.  Occasionally it’s 2.  I’ll make this very simple: it’s 3.  Make a note of it.  If you’re using a 2, 4, 5,  or some number other than 3, stop explaining why you prefer that number, and CHANGE it.
    • If the language you are using enforces a certain indent, I’m not talking to you.
      • If you are in your basement wearing a tinfoil hat developing another language that you think will solve the issues with all the ones available, and your language will enforce a certain indent level, make it 3.  That is now the standard.
        • Stop it.  There are 4,397,531 computer languages.  Yours will not solve all the other problems.  It will have it’s own share.
  • Tabs.  Some people like to use tabs to indent, and have them match the indent amount.  Some people like to set indent to one value (it had better be 3), and then set tabs to a larger number (maybe 8), so that it compresses the file somewhat.  So on a line that is indented four times, you get one tab and 4 spaces, thus saving 7 bytes.  So, when should you use tabs?  NEVER. Tabs have NO place in source code. You don’t need to save the space. Attempting to save space cost us a lot of time and money with the whole Y2K 2-digit year fiasco. Here is a 1TB hard drive for $60. Buy two and use all the spaces you need. If you need to compress the leading whitespace in your code, you’re doing it wrong.  SlickEdit it has a nifty feature to help you convert your tabs to spaces (Edit>Other>Tabs to Spaces).  Get to work.

If you’d like to wait until after the holidays to implement these changes, I understand.  If you’re waiting until after December 21st to see if you should waste your time in case the world ends because the Mayan calendar stopped there: they probably just stopped there.  They probably just took it out a couple thousand years and said “that’ll do”.

In observance of Election Day, we had planned to do a mock presidential debate between two competing technologies. Think Lloyd Bentsen debating Dan Quayle in the late 80s.

Moderator: The question back to you, Hg. What qualifies you to be the version control system of choice?
Mercurial: My implementation of distributed repositories is well regarded, and third party tool support is coming along nicely. If you look at my operating system support, you’ll see I support as many platforms as CVS did.
Subversion: Hg, I was born from CVS. My command syntax closely reflects that of CVS. I know CVS well as we have served side-by-side in datacenters across the globe. You sir are no CVS!

Or perhaps the classic Ronald Reagan and Jimmy Carter exchange

Java: Garbage collection, memory management, no pointers. These are the issues important to developers that compiled languages are typically against.
Moderator: C++?
C++: There you go again…

So as you can seen, politics and software technologies don’t really mix all that well. In fact, the results can be disastrous. We experimented with running a sophisticated source code indexing algorithm against internet-hosted code repositories. The indexing daemon was inadvertently pointed at site hosting political quotes. Behold the train wreck that ensued.









So, you’re in your basement listening to Pink Floyd albums on vinyl, and wearing a tinfoil hat, and writing a version control system.  Your version control system is going to fix the problems of the 783,711 version control systems – free and commercial – that already exist.

Mathematically, it stands to reason that you are going to overlook something.  We have already established that there are 783,711 version control systems available, yet there you are with the same Pink Floyd album side playing over and over writing #783,712.  Because all of them didn’t do it right.  So the odds are you won’t get it exactly right either.  Maybe you’re not quite as clever as you think, or maybe your foil isn’t quite thick enough.  Or maybe you just overlooked something I find very important.  So here we go (in no particular order):

  • Under NO circumstances should the default check-in behavior be to delete the local file.  I’m going way back on this one… but this one bugs me.  When I have to write support for a version control system, I try to use it’s default options as much as possible.  And in this case I did too.  However, I found it such a terrible default it bears mentioning here.  Perhaps it made sense to somebody at a point in time when hard drive space was measured in megabytes.   But not to me.
  • Let us suppose your version control system supports separate repositories at a pre-specified location.  For example you set an environment variable:

If you allow multiple repositories (or modules, herds, gaggles or whatever you choose to call them) to be stored at TINFOIL1,port:80, I should be able to list them all.  There should be a command I can run to see all of them.  If your version control system uses a URL where only one thing can exist:


then this does not apply to you.  I do not have an opinion about which one is better, although the URL method seems to be more modern.  But if there is more than one thing, let me see it – do not make a colleague of mine and I sit and try things until we notice that there is a command that you can run that gives an error message for each module, and we can get it that way. I shouldn’t have to do something wrong in order to stumble across a correct answer.

  • Let me view all versions of a file  across branches.  I won’t go into detail here because I covered this in Manifesto – Part 1 – Branching.  But it is important enough it bears mentioning again.
  • Let me get a file, and put it where I want it.  Do not make me get the whole directory.  Do not make me get the whole directory structure, with just one file in it.  Let me get any version of any file, from any branch, and put it anywhere I please.
  • Let me run any command and specify the output in XML, or some other regular format.  I am adding support for this version control system to SlickEdit after all.  I don’t want to use your API.  I want regular output written to a file I specify, or that I can redirect to a file.
  • When running a version control command, a history or log command for example, let me refer to the file any way available to me.
    • If I am on Windows, let me refer to the local file, using a relative or absolute path, OR using the URL (or whatever the remote specifier is).
    • Do not make me use forward slashes in relative paths while I am working on Windows.
    • Do not make me change to a directory that was checked out and use a relative path.
      • I should be able to sit in “c:\temp” and run “tinfoilvcs history c:\src\project1\file1.cpp”.
  • Let me checkout multiple copies of the same branch/module/whatever.  Most recent version control systems do not have issues with this.  But I often find myself in a situation where I need to fix a bug, but my copy of the branch I am working on is “too dirty”.  So I checkout a new copy, fix the bug, check it in, delete the new copy, and update the other copy.

For extra credit:

  • Let a user plug in a 3rd party GUI diff on their own – so if they would like to run vsdiff.exe to view differences even if they run your version control’s diff command from the command line, they may do so.
  • In the above paragraph, replace “diff” with “3-way merge”.

Now go flip the record over.

« Previous PageNext Page »