Version control and workflow
May. 24th, 2013 01:43 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
sawylPrompted by a other peoples' comments on the relative merits of git versus subversion etc, I've been wondering whether the time hasn't come to reconsider our choice of version control. Although a shared CVS repository has worked reasonably well for the last decade, I've noticed a couple of shortcomings that are becoming increasingly problematic. Firstly, there is a general feeling that version control is a nusance rather than a positive tool and a bad tendency not to check changes into the tree seems to have emerged. Secondly, because the tree is shared, there is a tendency to rough out a piece of code, schedule a change, add it to the tree (or not, as the case may be), only to find that it doesn't actually work.
These problems, it seems to me, could be addressed by shifting to a system of distributed git repositories with a central repository.
This would allow people to take a copy of the master, work up their own changes checking in snapshots as they go, until they've got a fully tested version. This gives all the benefits of version control but removes the risk of checking a broken version of the code into the master. Then, once everything is prepared and tested, they can raise a change ticket, push the update back into the master confident that their changes will work correctly, and the master can then be used to update the production configuration.
This model has the advantage of moving commits from a single, final operation to an ongoing part of working up a change. It also makes life easier for the developer by giving them access to source code control as they work up their change, giving them a stronger incentive to commit all their changes to the tree. By using annotated tags configurations can be tied back to change tickets and by using signed tags, it becomes possible to validate particular releases — a particular problem when dealing with configuration information.
As if all that wasn't enough, git also does metadata versioning. Yes, I think it's definitely time to consider changing.
These problems, it seems to me, could be addressed by shifting to a system of distributed git repositories with a central repository.
This would allow people to take a copy of the master, work up their own changes checking in snapshots as they go, until they've got a fully tested version. This gives all the benefits of version control but removes the risk of checking a broken version of the code into the master. Then, once everything is prepared and tested, they can raise a change ticket, push the update back into the master confident that their changes will work correctly, and the master can then be used to update the production configuration.
This model has the advantage of moving commits from a single, final operation to an ongoing part of working up a change. It also makes life easier for the developer by giving them access to source code control as they work up their change, giving them a stronger incentive to commit all their changes to the tree. By using annotated tags configurations can be tied back to change tickets and by using signed tags, it becomes possible to validate particular releases — a particular problem when dealing with configuration information.
As if all that wasn't enough, git also does metadata versioning. Yes, I think it's definitely time to consider changing.
