Talk:Distributed version control: Difference between revisions
imported>Pat Palmer (need workflow graphics) |
imported>Pat Palmer (more feedback) |
||
| Line 12: | Line 12: | ||
==workflows difficult to understand without a figure or graphic== | ==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.[[User:Pat Palmer|Pat Palmer]] 20:33, 16 August 2010 (UTC) | 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.[[User:Pat Palmer|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.[[User:Pat Palmer|Pat Palmer]] 20:39, 16 August 2010 (UTC) | |||
Revision as of 14:39, 16 August 2010
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)