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)

balance in assessing distributed vs. centralized

The article makes the following statement: "Merging is certainly possible in a centralized system, but is tedious and can be complicated." References and/or examples might bring balance to a claim like this.

Distributed and centralized are two very different ways of working. DVC developers apparently 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 (I surmise--the article doesn't exactly say this). What disturbs me is the claim that all centralized system won't work unless a server is running. I didn't find that to be the case. I always had a local copy of all the files--but I could only check back in the ones which I had previously checked out. Check-in/check-out as a model has all the same contraints that mutually exclusive locking has in concurrency--exactly the same set of advantages (safety, avoidance of duplication) and disadvantages (people may have to wait on each other for changes).

Can I feel confident that the distributed model never leads to complications, that multiple developers don't sometimes change the same file in incompatible ways, and all but one of them ends up "losing" their work? 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.

Finally, what about scale? If there are 200 developers working on a single software system, do the chance of collisions go up, as opposed to, say, just a dozen developers? IMO, one problem seems to be, that few people have extensively used both kinds of VC system. Without having used them both a lot, it becomes difficult to make objective comparisons. For example, I have used a couple of different centralized systems that both worked well (Bell Lab's proprietary system in the 1980's, and Microsoft Team System). However, they were not free. Is the argument that DVC is pretty good AND FREE what's really going on? I can accept that argument, but let's state it baldly if freeness is a key motivation in choosing a tool.Pat Palmer 13:32, 24 August 2010 (UTC)

a GIT question - what languages can it handle?

What programming languages can Git handle? Is it OK if I am using Python? Does it work for Microsoft languages? For example, in order to use Visual Studio, it is necessary to have ALL files in the project available and in a certain folder structure. Many centralized systems are incompatible with Microsoft programming because they only dole out one or two files at a time, which is one reason why Microsoft created their own versioning code repository (Team System, unfortunately very expensive). So can I do my C# programming using Git as version control? Can I do Python? PHP? Any language at all? Is there any restriction?Pat Palmer 13:53, 24 August 2010 (UTC)