Talk:Distributed version control: Difference between revisions

Content deleted Content added

Inline

Revision as of 17:03, 27 January 2011

Cleanup

I just tagged this article for cleanup, but sourcing is another issue. Please don't be offended if you have been working on this article. I have put the tag up for the following reasons:

The article is rather 'listy'.
the article is mainly unsourced
The section headings don't follow the Manual of style.
There are many external links in the article, that should be replaced with wikilinks, or not be linked at all.
The statement "fairly recent" in first paragraph is not a statement that will age well. Give an approximate year at least.
The introductory part after "other differences are as follows" is confusing organizational issues (peer approval, and all that Linus styled organization) with the actual DVCS differences with centralized VC. After all, you can organize centralized repository access in same manner, even distributed repositories.

If someone could provide some sourced from which this article is built, I'll be happy to help out improving it. Martijn Hoekstra 19:12, 2 November 2007 (UTC)[reply]

Merger proposal

I propose Distributed revision control & revision control#Distributed revision control should be merged in one way or another.--Grimboy (talk) 17:27, 1 January 2008 (UTC)[reply]

Comment: If the merge happens, I think it should be from this article to Revision Control, not the other way around. RossPatterson (talk) 20:08, 1 January 2008 (UTC)[reply]

Comment: I agree with RossPatterson. Whether or not distributed revision control needs a separate article, the main article needs to cover distributed revision control. Both topics gain from close comparison. If merging, merge from Distributed revision control to Revision control#Distributed revision control. --Michael Allan (talk) 21:45, 1 January 2008 (UTC)[reply]

Comment: Merging is a bad idea. This part just tells readers DVC exists and a little about how it differs. This is 1005 legit. and nec. for a rounded view of the topic of VC. Very fine details of course belong in DVC's own entry. Removing this could potentially leave the reader ignorant of DVC. —Preceding unsigned comment added by 24.12.136.199 (talk) 02:23, 29 December 2009 (UTC)[reply]

Comment: I disagree with the merger. Maybe its just my preference, but I feel that good articles need some degree of overlap with their sub-topics, with each of the replicated parts displaying different levels of detail. The lower level of detail in the overview should introduce and summarize the more detailed sub-topic referenced by in the hyper-link. This reduces the tendency for reading hyper-linked texts to become disjointed, whereby the reader becomes lost in an endless regression of definition, all at full detail. I think this section should remain as an introduction to the linked and more detailed sub-topic. --Daniel Collicott 09:55, 7 February 2009 —Preceding unsigned comment added by 78.105.184.242 (talk)

(1) Errm, I don't get this. Someone suggests a merge; a couple of people agree; after a year nobody has disagreed, and yet the merge has not taken place?

(2) I think a merge would be a good idea, but if not then this article needs completely rewriting, as it is appallingly badly written. For a start, nowhere does it tell us what "Distributed revision control" is. JamesBWatson (talk) 19:30, 22 April 2009 (UTC)[reply]

I agree that the articles should be merged. It is a huge problem when a single topic is broken down into pieces placed on separate pages. The purpose of a encyclopedic presentation of information is to find that information in one place. A longer page is not a problem, but separate pages are. Daniel's objection may well be solved by the proper use of XOXO within wikis like this. But that is a separate issue. In the mean time, I believe that the use of clear sub-headings will solve the problem. - KitchM (talk) 18:19, 20 October 2009 (UTC)[reply]

Diagram

A diagram of some kind illustrating the differences between centralized and distributed VC would help a lot —Preceding unsigned comment added by 83.89.0.118 (talk) 15:28, 23 June 2008 (UTC) Exactly! --62.153.161.241 (talk) 07:37, 18 January 2010 (UTC)[reply]

History

The article says that "The first DVCS is Reliable Software's Code Co-op (1997)". However, I've just run across an academic paper describing one earlier than that: 'O'Donovan, B.; Grimson, J.B., "A distributed version control system for wide area networks," Software Engineering Journal , vol.5, no.5, pp.255-262, Sep 1990'. It was implemented over UUCP (!) although to be fair, they say they wrapped UUCP calls in an abstraction layer so it could be replaced. Should this be added to the history section? —Preceding unsigned comment added by Ajb (talk • contribs) 13:39, 28 July 2008 (UTC)[reply]

Sure, that's really intersting. RossPatterson (talk) 13:01, 15 August 2008 (UTC)[reply]

I started using Sun Microsystems TeamWare around 1990 or 1991 while working for Cray Research on their CS6400 computer which ran Solaris 2. Our team ported Solaris 2 to the CS6400 and used TeamWare because that is what Sun used for the OS Networking source base. TeamWare was a full DVCS even back then. I'm not sure how long Sun had been using it before then. Does anyone here know how to contact Larry McVoy (who designed TeamWare and BitKeeper)? He would probably have much more detailed knowledge of the history of DVCS. In any case, it was a long time before 1997.

Billdav (talk) 19:30, 30 March 2009 (UTC)[reply]

First generation open-source DVCSes include Arch and Monotone. The second generation was prompted by the arrival of Darcs,

It is not clear, in which sense the DVCSes are names first and second generation. There are no other mentions on the page. Also, from brief search it seems to me that Arch origined in 2001, Monotone in 2003, Darcs in 2002.

Dendik (talk) 20:28, 28 September 2009 (UTC)[reply]

locking?

hi guys,

might locking be a feature people used to svn might miss in dvcs. i see no way of having lock-modify-commit in dvcs but arts people only want it this way. —Preceding unsigned comment added by 195.143.104.254 (talk) 14:08, 19 January 2010 (UTC)[reply]

Disadvantages are just FUD

The "disadvantages" section contains a couple of myths about DVCS that aren't actually true. They aren't harder to use, on the contrary their key selling point is that they make the hard things (branching and merging) very easy. Also, cloning a git or hg repository isn't much slower in practice than a Subversion checkout. Maybe by a factor of two or so at most, but no more, and besides, it's only the kind of thing you do occasionally so it's pretty much a non-issue. 194.60.38.198 (talk) 08:36, 17 June 2010 (UTC)[reply]

Not everyone in the world has fast internet and "factor of two at most" is huge when it is a matter of 1 hour vs. 100 hours for a huge project. Your FUD allegations are just arrogant. — Paul Pogonyshev (talk) 11:01, 12 July 2010 (UTC)[reply]

One hour versus 100 is a factor of 100, not a factor of two, and you'd be looking at seriously huge projects to see anything near that kind of difference. Incidentally, the other evening I compared a Subversion checkout of the Django project with a clone of the Git mirror on github. Despite the fact that it's over 13,000 revisions, I found that git cloned the entire history in half the time taken by a Subversion checkout. 194.60.38.198 (talk) 11:56, 16 July 2010 (UTC)[reply]

He means.. if your project takes 1 hr to checkout, then taking 2 hrs is probably annoying but can be lived with. If it already takes 100hrs then doubling that adds an extra four days to your schedule. Exxaggeration maybe, but valid none the less, operation speed matters a lot to some people. If you use continuous integration this can become very important because it affects your peak integration speed. EasyTarget (talk) 13:51, 28 October 2010 (UTC)[reply]

firstly, thanks to EasyTarget for explaining to the user 194.60.38.198 what Paul Pogonyshev meant. Hehe. I also disagree to a merge. the revision control article really meets Wikipedia 'Standards'. i.e. its written with references (or source) thus, its more believable/factual. the DVC article is written without references and written in a 'rebellious' style. Ofcourse DVCS are 100% legit.But this article is not.! Also, the info. given in the main article(revision control...) about Distributed revision control systems is enough. to user JamesBWatson- i think these are the reasons why "the merge has not taken place"

Well the current wording "...disadvantage of DVCS, one could note..." is awful: a real 'wonks grudging acceptance that this favourite toy might have a blemish'.

No system is perfect, things that make DVCS systems really great for freewheeling distributed agile/scrum developments can make it really hard work for other models.

EasyTarget (talk) 13:52, 28 October 2010 (UTC)[reply]

@@ Line 25: / Line 25: @@
 :(1) Errm, I don't get this. Someone suggests a merge; a couple of people agree; after a year '''nobody''' has disagreed, and yet the merge has not taken place?
 :(2) I think a merge would be a good idea, but if not then this article needs completely rewriting, as it is appallingly badly written. For a start, nowhere does it tell us what "Distributed revision control" '''is'''. [[User:JamesBWatson|JamesBWatson]] ([[User talk:JamesBWatson|talk]]) 19:30, 22 April 2009 (UTC)
 :I agree that the articles should be merged.  It is a huge problem when a single topic is broken down into pieces placed on separate pages.  The purpose of a encyclopedic presentation of information is to find that information in one place.  A longer page is not a problem, but separate pages are.  Daniel's objection may well be solved by the proper use of XOXO within wikis like this.  But that is a separate issue.  In the mean time, I believe that the use of clear sub-headings will solve the problem. - [[User:KitchM|KitchM]] ([[User talk:KitchM|talk]]) 18:19, 20 October 2009 (UTC)
@@ Line 68: / Line 69: @@
 :: One hour versus 100 is a factor of 100, not a factor of two, and you'd be looking at seriously huge projects to see anything near that kind of difference. Incidentally, the other evening I compared a Subversion checkout of the Django project with a clone of the Git mirror on github. Despite the fact that it's over 13,000 revisions, I found that git cloned the entire history in half the time taken by a Subversion checkout. [[Special:Contributions/194.60.38.198|194.60.38.198]] ([[User talk:194.60.38.198|talk]]) 11:56, 16 July 2010 (UTC)
 ::: He means.. if your project takes 1 hr to checkout, then taking 2 hrs is probably annoying but can be lived with. If it already takes 100hrs then doubling that adds an extra four days to your schedule. Exxaggeration maybe, but valid none the less, operation speed matters a lot to some people. If you use continuous integration this can become very important because it affects your peak integration speed. [[User:EasyTarget|EasyTarget]] ([[User talk:EasyTarget|talk]]) 13:51, 28 October 2010 (UTC)
+firstly, thanks to EasyTarget for explaining to the user 194.60.38.198 what Paul Pogonyshev meant. Hehe.
+I also disagree to a merge. the revision control article really meets Wikipedia 'Standards'. i.e. its written with references (or source) thus, its more believable/factual. the DVC article is written without references and written in a 'rebellious' style.
+Ofcourse DVCS are 100% legit.But this article is not.!
+Also, the info. given in the main article(revision control...) about Distributed revision control systems is enough.
+to user JamesBWatson- i think these are the reasons why "the merge has not taken place"
 :Well the current wording "...disadvantage of DVCS, one could note..." is awful: a real 'wonks grudging acceptance that this favourite toy might have a blemish'.