Megalomania in Revision Control Systems

The more I work with Perforce the more annoyed I get with it’s belief that it is the center of the software development process. Not that Perforce is not unique in believing this. In fact, many commercial revision control systems have this same megalomania.

So, commercial revision control vendors, let me clue you in. Revision control systems are not the center of the software development universe, the file system on the developer’s machine is. Period. The primary job of a revision control system is to figure out what the developer did, after the developer has already done it, and to save that so that it can be applied to the other developers local file systems.

I am complaining about this because out of the box Perforce does not include a way to examine your working directories and get a list of what has changed since the last time you synchronized with the depot (Perforce’s word for a repository). This means that you must declare any changes you make to the source code tree before, or at the same time as, you make them. If you do not declare the changes up front it is almost certain that some required changes will be forgotten and will not get checked in.

The main problem with this approach is that it compels you to break your flow. You might not think that just having to execute one additional command would really be that bad. After all, executing a command could probably be incorporated into your personal process and thereby have little or on impact on your flow. In practice, however, it really does break the flow.

The true cost of declaring that a new file will exist with a particular name is not in the act of declaration. Rather, it is in the thought and commitment that such a declaration requires. Every day, I created new classes only to notice a couple of minutes later that it has morphed in to something quite different than what I originally intended. Declaring the name of a new file to the revision control system before I have even created it dramatically raises the cost of such emerging behaviors. To name a file well I need to understand it’s purpose and to do that I usually need to create it and put some code in it to see how it turns out.

Having to declare the name of the file first requires a significant amount of thought and, worse of all, it prematurely solidifies the design. This premature solidification of design is costly both in terms of the time it takes and the quality risks it introduces. Paul Graham makes a compelling case for a fluid approach to software design in Hackers and Painters. Forcing stability on an immature design merely locks in its deficiencies and that is exactly the result of requiring the declaration a file before it is created.

The need to declare modifications and deletions up-front is less onerous. Deletions are easier because, generally, it is easy to understand the consequences of deleting a file because there is only one. Modifications are easier because marking a file at “to be edited” is quite forgiving. Even if you failed to actually modify the file checking it in will have no functional impact. None the less, having to declare you intentions up-front is still annoying, and wasteful since they could be determined after the fact.

If you are a commercial revision control system vendor please take note. You are not, nor will you ever be, the center of the software development universe. Pretending that you are just costs your users time and effort that could be better spent solving real problems.

7 comments on “Megalomania in Revision Control Systems

  1. -

    At this point, if I were you I would be asking myself whether I wouldn’t be better off using an alternative version control tool for my source code, and just rsyncing to the p4-controlled directory for checkins.

    I do this all the time with clients — I manage stuff in my local VMware instance of their production setup in e.g. darcs, and when I’m ready I push changes ‘over the wall’ to whatever version control system they prefer.

    Darcs even has a tool to support this more elegantly than using rsync (tailor) … ymmv.

  2. - Post author

    Oh, I am asking my self that question and I would definitely be better off using an alternative version control system. However, Perforce is the anointed tool here so that is what I have to use and Tailor does not seem to support Perforce.

    Interestingly, I created p4-status to deal with code drops from an external contractor. I need a way to detect the additions and and deletions he had made since the last drop.

  3. -

    Or actually WinMerge alone might just do it for you, if external contributor code diff’s is the motivation.

    That’s what I use to determine the reverse — what the client has added since the my last code grab. :-)

  4. -

    Hi Peter,

    Can you give me an approximation of what you pay for Perforce version control at your company. I’m doing a little research for a school project and am trying to get a sense of what these tools cost. I assume a company would pay about $600 / user for the first year and then a reduced cost for maintenance every year there after. Is this a correct assumption?


  5. - Post author

    Donna, I really have no idea of what we pay for Perforce.

  6. -

    […] week I did some work on a project that uses Subversion and, man, what a difference a year makes. Back then I dreamed of being able use Subversion instead of Perforce. Now using svn feels a bit like walking around waste deep in […]

Comments are closed.