Jump to content

Talk:Distributed version control

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Viam Ferream (talk | contribs) at 09:37, 21 January 2016 (→Expert opinion). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

What does this mean?

"to work on a given project without requiring that they maintain a connection to a common network." This doesn't make any sense. What is a "common network" entailing? How does one work on a "given project" without requiring that they "maintain a connection to a common network." make sense? — Preceding unsigned comment added by 169.139.19.96 (talk) 20:41, 13 March 2014 (UTC)[reply]

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:

  1. The article is rather 'listy'.
  2. the article is mainly unsourced
  3. The section headings don't follow the Manual of style.
  4. There are many external links in the article, that should be replaced with wikilinks, or not be linked at all.
  5. The statement "fairly recent" in first paragraph is not a statement that will age well. Give an approximate year at least.
  6. 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" 

                  -------Rampuse 59.96.88.156 (talk) 17:05, 27 January 2011 (UTC)[reply]
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]
I think that a general speed difference is difficult to hold. Git, for example, is a very, very fast system (git commands on a native Linux system with modest hardware take typically times of a hundreth of a second), which is usually much faster than non-distributed version control systems such as Microsoft Team Server. Also, a speed difference in the initial pull of a repository is in almost any practical case not relevant at all, because it will either be much less than a second or the project is exceptional large and the time to understand a project and get it running the first time will be much much larger than the time required for the transmission.
The other critic is that binary files cannot be locked. However, locking leads very often to problems and solves very few problems. It is possible to construct cases in which locking will be needed, such as an image processing company with many people working in parallel on the same binary files, however in software development, this just does not apply. --84.135.67.155 (talk) 22:06, 27 May 2011 (UTC)[reply]

"Every working copy is effectively a branch."?

In my wording would be "Every working copy is effectively a fork." As a copy does not necessarily mean commits and commits are needed to talk of a branch. Branching happens whenever one revision has more than one successor. Changing that in the article ... —Preceding unsigned comment added by 188.174.24.74 (talk) 11:22, 10 March 2011 (UTC)[reply]

pull request

Pull request redirects here but there's nothing in the article defining the term. Looks like a TODO. 2.101.108.194 (talk) 11:59, 16 October 2012 (UTC) , pbhj[reply]

Yep - I second this - same thing just happened to me.Iamsorandom (talk) 13:39, 16 April 2013 (UTC)[reply]

Me too - now it's almost 2 years ... JB. --92.195.48.144 (talk) 15:05, 15 April 2014 (UTC)[reply]

It's not really a technical term or VCS feature. It just means you make a patch in your local repository and then ask someone maintaining an upstream repository to pull your change. It's like the "edit request" you made here on Wikipedia by posting to the talk page. Github has an actual pull request button, but again, that just posts some alerts for people to look at. Added: I guess LKML has a bit of formal process around pull requests, but I'm not a participant and am not sure how it works. 70.36.142.114 (talk) 16:47, 13 May 2014 (UTC)[reply]

Distributed version control vs. Distributed revision control

Why name this article "Distributed revision control" instead of "Distributed Version Control"?

It is interesting to see that if you lookup that expression on Google, apart from this article and the Revision control article, the first page of results is mostly pages on DVCS, not DRC or DRCS.

On a more quantitative and objective note, Google Fight place DVC an order of magnitude higher than DRV (litterally: 9,960k against 979k at the time of writing). Nowhere man (talk) 17:10, 18 May 2013 (UTC)[reply]

Expert opinion

I'm hoping an expert could polish the prose on this article. Or perhaps suggest a merge with Revision control? Given the separate treatment of this topic, the current structure seems ripe for rethinking. — HipLibrarianship talk 01:48, 28 August 2014 (UTC)[reply]

Experts are not needed for prose polishing or proposing a merge, so I'm removing the tag. RockMagnetist(talk) 02:24, 4 September 2015 (UTC)[reply]
  • Merging this into revision control would be an awful idea. Version control has decades of history behind it, but distributed revision control is much newer (8-9 years?). It's a different approach and wikipedia really needs a better article to explain it. The current one... doesn't. "Experts are not needed" indeed! Like that has worked.
Also why is this called "distributed version control" rather than "distributed revision control"? That's reasonable, although a bit out of date, for version control, but it gives quite the wrong idea when applied to the current generation of distributed (Git-like) systems. Viam Ferream (talk) 15:45, 20 January 2016 (UTC)[reply]
That ship has sailed - see the discussion at Talk:Version_control#Requested_move_13_July_2015. RockMagnetist(talk) 20:53, 20 January 2016 (UTC)[reply]
Yeah, one old guy sayinbg "I invented this back in the '80s and punch cards were good enough for my granpappy an' me, so that's how it's staying" What relevance does SCCS still have to anything distributed? Viam Ferream (talk) 09:37, 21 January 2016 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Distributed_version_control&oldid=700904502"