Linux Poster Boy Talks about SCM
Posted by Alec on 3 June 2007
Códice Software: Linus Torvalds on GIT and SCM
speech Linus Torvalds gave some days ago at Google, basically talking about GIT and Source Control Management
Codice Software have a nice blog entry about Linus’ presentation on Source Control Management. He does a nice job of expounding on the value of distributed version control — worth watching. There is further analysis by Kyle Cordes
However one question that is not obvious with distributed SCM is how to link commits to issues in the bug database. Do we we need a replicated bug database? If we we record the commit in a central database then we have a problem because we may not have access to the corresponding code…
Powered by ScribeFire.
Kyle Cordes said
Here are a couple of thoughts on the notion of linking a distributed source control system to an issue tracker (a useful feature, certainly).
A distributed system, like a centralized one, could have text in commit notes which link to an issue tracker #; and likewise an issue tracker could be informed of which source revisions (referred to by a hash, in most distributed systems) address issue #n. Assuming that the issue tracker is not distributed, it might not find out about such new revisions until they make it back to a central respository. If the developer happened to be connected to the network when they make the fix, they’d likely push the commit over right away. If the developer happens to be offline (typical example: on an airplane) when they make the fix, the issue tracker would find out about it later, when they get online and push changes.
As a general rule, to make a distributed source control system play well with a centralized other system (like an issue tracker or a build server), you nominate some repository as a central one, and have the centralized tools talk to / monitor that one for integration.
Alec said
That suggestion certainly makes sense and seems like a good way to make them play together.
Another idea that comes to me at odd times is to maintain the tickets as configuration items in the source control system. You can make something like that work in svk because Subversion supports attributes on configuration items.
A way to bring the two approaches together is to
1) Maintain a traditional issues and bugs database
2) Create proxy CI’s in the distributed source so that i) all the information from the bug can be accessed in the aeroplane and ii) correct bug is updated when the code is merged back (assumes the bug report and code are on the same branch)
I really need to think that through a little more…