Talk:Distributed version control
overall comments
This is a great beginning. The article as it stands today makes some excellent points and is (IMO) a substantial improvement over what exists in Wikipedia. Some of the work which might still be done is detailed in the following subsections:Pat Palmer 20:41, 16 August 2010 (UTC)
deep web references
I went to the Penn library online course guide, selected the very first database (ABI/Inform), and got this hit on "distributed version control": O'sullivan, Bryan. "Making Sense of Revision-Control Systems." Communications of the ACM 52.9 (2009):56. http://elinks.library.upenn.edu/sfx_local?genre=article;sid=ProQ%3A;atitle=Making%20Sense%20of%20Revision-Control%20Systems;title=Association%20for%20Computing%20Machinery.%20Communications%20of%20the%20ACM;issn=00010782;date=2009-09-01;volume=52;issue=9;spage=56;au=Bryan%20O%27sullivan This would make a useful supplement to this article.Pat Palmer 20:13, 16 August 2010 (UTC)
broken link in references
The third reference (this link: http://progit.org/book/ch3-2.html/) appears to be broken.Pat Palmer 20:24, 16 August 2010 (UTC)
intro would benefit from revisions
The introduction needs to state that "Distributed" version control is a special type of "revision system" (or something like that). I think that the very long quote in the introduction should be removed, and the information should be paraphrased instead. Using a long quote at the very beginning breaks up the introduction and makes it awkward to read. The definition is a good one but could simply be reworded. A later sentence could list the possible synonyms. In addition to defining DVC, the intro needs to give snapshot overview of what the article which follows is about.Pat Palmer 20:29, 16 August 2010 (UTC)
workflows difficult to understand without a figure or graphic
The sections on workflows would really benefit (IMO) from a graphic like that provided in one of the references (with the "Blessed Repository" labels). If permission to use those graphics cannot be obtained, they could be recreated anew for this article (with adequate credit given to their source), or else strong statements directing the reader to the graphics in the other article could be included. Without those graphics, or something equivalent to them, the explanation of how changes get merged back in become muddled.Pat Palmer 20:33, 16 August 2010 (UTC)
Integration with change control
The article currently does not mention how version tracking can be tied with change control--a very important feature of some central repositories. The description of trade-offs between distributed vs. centralized seem a little skewed towards distributed. Probably they should be presented as different instead of "better" or "worse" than each other. Also, it's best not to confuse the speed of a particular implementation as being a virtue of all products of the same class (i.e., performance); in this day of fast networks and processors, there is no reason why a reasonable centralized repository could not allow local compilation of all files (but "ownership" of only some of the files used for compiling), as well as reasonable performance on check-out and check-in. Just because some systems do not have good performance, let's don't throw all systems in the same classification down the drain automatically.Pat Palmer 20:39, 16 August 2010 (UTC)
check-out and merge granularity
Whether distributed or centralized, the issue of merge granularity arises. I wonder if there are not different rules of thumb for distributed vs. centralized. This article could address this. See this blog: http://www.codinghorror.com/blog/2008/08/check-in-early-check-in-often.html .Pat Palmer 21:41, 16 August 2010 (UTC)