Developing with DVCS

Distributed Version Control Systems are a huge improvement in the system development process for a number of reasons but its easily researched on Google. So, I'm not going to get into to all the issues. Some thoughts

  1. There are only branches and revisions.
    • Think of code development as a process through time and space.
    • Space is discretized into developers
    • Time is discretized into commits
    • Add a little meta data linking points in the developer / commit sequence and you have a graph describing the evolution of the code. Throw on some collision free identifiers (SHA-1) and you have the complete genetic history of every line of code
    • Repositories are a cache / detail without significance in and of themselves
    • don't forget to push often so others can import your changes
  2. Only push to repos you own
    • This is probably the least understood aspect of DVCS. The key concept to understand here is that as long as you can get other people's work, you should be pulling and merging from their repos, and only pushing to your own. An example is the repo on your laptop being pushed to your repo on the server for publishing.

    • When your repo is published, others can pull / merge / publish. By convention, cerain people's repos, specfically, certain branches on well known repos will have meaning.
    • There are no permissions required which turns version control on its head. You publish your work, make it known (the usual suspects), and it can be pulled by anyone with interest and as part of the process used by a specific project
  3. You are not your code - http://blog.red-bean.com/sussman/?p=96

  4. Relevant Videos - on Git but the concepts are explained


CategoryDevelopment

DsageNg/HgDevelopment (last edited 2008-11-14 13:42:04 by localhost)