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)

references, examples might bring balance

Just for example, the article makes the following statement without providing either an example or a reference: "Merging is certainly possible in a centralized system, but is tedious and can be complicated." Why is merging less tedious in a distributed system if a human being has to first test the change to be merged before allowing it into a "blessed repository"? Distributed and centralized are two very different ways of working. DVC developers are given the remarkable freedom to change any and all files at once, whereas centralized developers can only change a few files which have been checked out exclusively to them. Can we really believe that the distributed model never leads to complications, that two developers don't sometimes change the same files in incompatible ways, and then that one of them ends up "losing" their work? IMO, this article does not really address these issues. I would like to see a neutral assessment of characteristics of distributed vs. centralized, reinforced by a specific example, and a reference, perhaps, to show that a statement such as the above has been found to be true in other assessments.Pat Palmer 13:17, 24 August 2010 (UTC)