Version Control - Part 2: Update/Commit
The problem with Checkin/Checkout
Generally speaking, Checkin/Checkout interrupts developers. You want to finish your task, but you can't continue on a portion of it, which then interrupts your thought process.
The more developers you have with the Checkin/Checkout model, the more interruptions each developer has and then development as a whole slows down.
The Answer: Update/Commit model
The Update/Commit model addresses this by allowing developers to edit the same files at the same time. No one has to wait. No one gets their thought process interrupted.
The two operations you have available are Update (download new code to your machine) and Commit (Upload your changes to the server). SVN's docs have a detailed explanation here.
The Update/Commit work cycle is:
- Update (download source code from the server)
- Edit
- Update (download and resolve conflicts)
- Commit (upload source code to the server)
But, are you ready for two developers editing the same file at the same time? Most developers are wary about making this leap. After awhile you find that it isn't an issue. Why isn't it an issue? Surely you'll have the same number of problems as with Checkin/Checkout?
Resolving Conflicts
Actually you have fewer problems with Update/Commit as compared with Checkin/Checkout. Every time two users want to edit the same file under Checkin/Checkout, it interrupts one developer which is a problem. However when two users edit the same file and commit the change to the server, there are two advantages:
- Resolving the conflict happens when committing the work, not when editing, which does not interrupt developers' thought processes.
- Most conflicts can be resolved automatically by the version control software. I find that 90% of conflicts can be handled automatically.
If you find that you have to manually resolve the conflict in a file, you typically have 3 versions of the file:
- Your changes to the file
- Someone’s changes to the file
- The final, resolved file. You edit this file with the goal of including your changes and other people’s changes.
Conclusion
Update/Commit is great. You and everyone else can work without getting into each other’s way and it seems like all the issues are solved. Why would you want distributed version control?
This is a very good methodology; i for one am glad we implement it!!
Keep up the good writing; always makes a good read especially when i understand some of the topics you write about!