Source Control

Source control is very important for maintaining software over time, especially if there are more than one programmers touching the code (and there should be)

Fave source control: Git - it's an example of reliable software with some great features - just the kind of software I like.

  • allows for very flexible workflow - can be tailored for the specific project you are working on
  • gerrit code review is really great, by far the best code review tool I've seen (Key advantages on almost every aspect over paid solutions like Atlassian's crucible)
  • Features like stash, gitk, rebase, add -i, rebase -i bring your source control up to speed with your IDE and make it a joy to manage multiple revisions simultaneously locally. If you have ever had one request interrupt an in-progress change, then you can benefit from this. (And if you've never had that happen, I have trouble identifying with you as a developer =P )
    • these powerful tools also allow developers to locally craft the code history they want to publish to the world - resulting in higher quality code and more maintainable projects
  • Reliable and trust-worthy - This is a big deal to me. After working with a product for a while, you get a feel for this aspect. By comparison SVN is VERY un-reliable - I've seen so many crazy errors with it. It's a well known pattern to re-checkout the code base and manually copy your local changes into the new SVN repo. I have never once had to even consider something like that with git. And mistakes are recoverable.
  • auto-detects renames and moves, doesn't require using the source control tool to do those operations in order for them to be reflected in history
  • git's command line completion is a thing of beauty - autocompleting commands, options, filenames (even non-existent filenames), branch names, versions, etc
    • Also there's shell integration to show the current branch and status in your command line prompt - quite convenient
  • Nice tutorial:

IMO Mercurial does not work nearly as well as git

  • no automatic detection of renaming files
    • like subversion this means renaming files screws up the history, the default diff between a renamed file is the whole file, maybe there's a way to actually diff it, but it's not easy/default like git
  • mercurial doesn't have any nice command line completion like git. It also
  • no add interactive
    • no index
  • no rewriting history (rebase, etc) - one of the most powerful features of git
    • can't squash and reorder commits before uploading, means that it doesn't work for both local and shared source control
    • no rebase interactive
    • This is due to a philosophical difference - The developers of Mercurial feel that the source control tool should stop developers from being able to re-write history (perhaps to avoid accidentally shooting themselves in the foot? or perhaps to avoid some sort of attack?)
      • Neither of these reasons are reasonable:
        • rewriting history *facilitates* fixing mistakes - and if you are being judged on your code, then it's important to be able to clean up the commits. In fact, if responding to pre-commit code review changes, it's quite important to be able to rewrite the history - unless you'd rather have your history cluttered with tons of junk that were never even in the code base.
        • this doesn't help prevent any kind of attack. The central repository should block rewriting published history, sure. But git allows for this also.
  • doesn't have built in support for accessing repos over ssh (inexcusable and reminds me more and more of svn)
  • no gerrit (my favorite code review system - of the ones I've used)
  • hg view is not as good at gitk
    • gitk shows uncommitted diffs (and index), but hg view only shows committed changes - eliminates half the usefullness of hgk
    • hg view doesn't have a refresh that will show new commits without quitting app and restarting
    • hg view / hgk has strange problems on mac
  • it's currently less popular, but even if it wasn't I'd like git better
  • OMG!!! HG = distributed SVN
    • SVN style problem:
      • apparently the default is to push everything to the remote server - not just your current branch, so you have to prepare your local repo in order to enable pushing. (this is bad - git allows many simulataneous threads of work that don't impact each other)
      • somehow during merge process it's easy to create commits that are not on the mainline, but are also labeled with the same branch (this is worse)
      • then it gets so terrible that in order to clean up the local repo the offical docs state "The recommended procedure to really eliminate unwanted heads" is to clone a new repository and copy over your changes. WTF!!!!!! This is not a valid use case for a non-exceptional situation. I have NEVER had to do this with git, let alone have the official documentation *recommend* doing it.
      • It's really not distributed if everyone shares the same integers for every commit.

IMO SVN is a poor implementation of source control. It's much better than nothing, but it's constant problems and it trains you (even unconsciously) to avoid anything but super core features.

  • It doesn't have tagging (their tagging implementation and even the command is a copy) - a copy is NOT a tag
  • Diffing doesn't work very well, so it trains you to not look at history
  • branching doesn't work very well, so it trains you not to branch
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License