Talk:Revision control

From Wikipedia, the free encyclopedia

 This article is within the scope of WikiProject Computer science, which aims to create a comprehensive computer science reference for Wikipedia. Visit the project page for more information and to join in on related discussions.
B rated as B-Class on the assessment scale
High rated as high-importance on the assessment scale

In software development, SCCS, or Source Code Control System, was developed by Marc Rochkind at Bell Labs, for use on the UNIX system, based on the ability of the ed program to display the differences between two code streams, which is the diff algorithm. The database of differences is the mechanism for capturing the difference in versions of the source code of a program. SCCS based the database on the original version. RCS improved on this by capturing the difference from the current version. CVS is a descendant of RCS. Even Wikipedia uses version control when displaying the differences between versions of an article, which are merely text streams, just like the source code of a computer program.

The concepts behind SCCS and RCS are identical, but the names of the operations differed. SCCS used get and delta, for example, but RCS uses co and ci. To this day, RCS, CVS, PVCS, SourceSafe, ClearCase are all compatible with SCCS (or .scc compliant)

As in the operation of a public library, RCS used the fundamental operations of check-in and check-out, abbreviated ci and co. A programmer could check-in the source code of a program into RCS, which would time-stamp the submission. Any programmer could get a copy of the source code for use, but only one programmer at a time, could check-in a version of the source code of a program. If a programmer were to check-out a program, that signals that the current version is locked for changes, until that programmer checks-in the program. 169.207.115.71 09:26, 22 Jan 2004 (UTC)

I removed this claim "(for instance, until recently, the Linux kernel)" from the following sentence(s):

At the simplest level, users can simply retain multiple copies of the different versions of the program, and number them appropriately. This simple approach has been used on many large software projects.

As far as I know, the linux kernel has been in revision control for a very long time. Burschik 09:13, 28 Jan 2005 (UTC)

Contents

[edit] "Revision" vs. "version"

Based on the redirection links, it appears that "revision control" is considered more canonical than "version control". I tried to make the article a bit more consistent by changing some references from "version control" to "revision control".

[edit] version number systems

I came hoping to find some information on how to number development in projects for example some products in development use alpha then beta development stages and some use version <1 like v0.21 and some use major.minor.maintainence systems such as v2.1.4 Could someone write something about this or does this not belong here, if so where would I find this. Nerdwithagun 08:03, 20 February 2006 (UTC)

[Edit] Some info on version numbers can be found here: Version.

[Edit] More info on version numbers can be found here: Software_versioning.

[edit] Marketing Pitch

Information about McCabe is a marketing pitch, not something that belongs in an encyclopedia. I propose to remove it from this article and from Configuration Management.

I just did. The same anonymous user also added it to Configuration management, in two different sections. If McCabe (or whoever this user was) wants their product listed on Wikipedia, they'll have to add it to the appropriate article(s). The links in these two articles are to general comparison and discussion web sites, not specific vendors. Imroy 06:01, 28 April 2006 (UTC)

[edit] Atomicity

The link for atomic goes to a disambiguation page. Can we be more specific as to which of the atomicity links it should refer to?

For the record, this is now pointing to Atomic transaction. I'm not sure if that's ideal (Atomic transaction is more from the DBMS point of view), but the only alternative targets i can find are more from the concurrent programming and/or hardare points of view, which aren't really an improvement. --Piet Delport 14:46, 2 July 2006 (UTC)
And now we have the Atomic commit page stub. Do we really want to have it, because all information contained there is also present here? --195.38.53.234 13:58, 17 September 2006 (UTC)

[edit] cleanup

see WP:CONTEXT. This article was targetted by a user targetting several other pages and overlinked it [1]. Its tagged for cleanup and I will try to get to it as time permits. Anyone willing to remove the overlinking before I get back to is as I'm still in the tagging phase would be greatly appreciated. --Crossmr 07:18, 18 June 2006 (UTC)

[edit] Distributed revision control

I'm a little confused by the term "distributed revision control" as used in this article and also in the "comparison of revision control software".

Say programmers Alice and Bob want to make improvements to some piece of software currently stored in a repository on Trent's machine.

  • Alice checks out the latest version from Trent's machine. Bob has to wait until Alice checks it back in.
  • Alice and Bob check out the latest version from Trent's machine. Software on Trent's machine checks for conflicts when they try to check it back in. If there are any conflicts, the first person to check in "wins", and Trent's machine sends a message to the other explaining how to try again.
  • Alice and Bob check out the latest version from Trent's machine. Software on Alice and Bob's machine checks for conflicts when they try to check it back in to Trent's machine. If there are any conflicts, the first person to check in "wins", and the other machine explains to its user how to try again.
  • There is no central repository. Alice checks out the latest version from Trent's machine. Once Alice publishes her improvements, Bob checks out those improvements directly from Alice's machine.

Do any revision control systems work like this last example -- without any central repository? --68.0.120.35 20:23, 2 December 2006 (UTC)

A better way to think about distributed revision control is that there is no such thing as checking in or out. Instead, every working copy is its own repository, and all changes are distributed by merging (pushing/pulling) between repositories.
In other words, to a distributed revision control systems, all repositories are equal: having a "central repository" (or not) is purely a matter of naming convention. --Piet Delport 19:36, 3 December 2006 (UTC)
Thank you, that's exactly what I wanted to know. Since this definition of "distributed revision control" makes more sense to me than what is currently in the article, I'm going to substitute this definition into the article. --68.0.120.35 01:27, 6 December 2006 (UTC)
Wow, sounds confusing. So if make a change to the codebase and you make a change to the codebase we will both have to manually merge each others changes into our local repos? Is that how its supposed to be understood? —Preceding unsigned comment added by 83.89.0.118 (talk) 19:12, 31 May 2008 (UTC)

Would this link be appropriate for the external links of the "revision control" article ?: "Please Stop Bugging Linus Torvalds About Subversion ... We, the Subversion development team, would like to explain why we agree that Subversion would not be the right choice for the Linux kernel."

Also WanDisco's software doesn't fit the description of a distributed revision control system. It is just a wrapper program around CVS or Subversion that keeps all servers in sync to look like a single repository. There is no pushing or pulling between repositories required by developers.

[edit] Lay Uses

Revision control is also useful for "lay people" (maybe even "la(z)y people) or at least I think it is. I think it's a good way to install software so that upgrades can be done with minimal pain.

Not being expert in this I can only suspect that svn, I mean Revision Control, is also useful in creating written documents. If this is the case isn't MediaWiki a form of Revision Control and shouldn't MW and Google Documents be discussed here as well?

I apologize if I am off topic, but I don't think I am alone in not understanding Revision Control, much less svn. If I am off topic please direct me to the appropriate article. --TMH 20:00, 22 March 2007 (UTC)

Integrated revision control is a key feature of wiki software packages such as MediaWiki, TWiki, etc. Comparison of wiki software lists revision control for several wiki packages. It's hard to imagine a wiki functioning very well without revision control; for example, the ability to revert a page to a previous revision is critical for defending a public wiki against vandalism and spam, to allow legitimate users to correct their mistakes, and to allow groups of editors to track each other's edits. I certainly think this warrants a mention in Revision control, but on Wikipedia we must cite our sources. It's not enough for something to be true or even obviously true; it must have been written about in some reliable source. I.e., we would need to find some reputable news article or scholarly paper which discusses the role of revision control in wiki software, so we could cite it here. We also need to avoid self-references. --Teratornis 22:11, 4 July 2007 (UTC)
The "avoid self-references" guideline makes the point that Wikipedia itself is a valid topic for articles, specifically identifying "[a]rticles where Wikipedia is illustrative of the subject, for example: online community, encyclopedia". The only thing to watch in this article is how those references are made, in case the material winds up elsewhere. And I have to admit, Wikipedia is at this point quite possibly the best-known example of a revision control environment. Oh, and the "cite our sources" guideline says that sources should be cited "[w]hen you add content ... that is challenged or likely to be challenged". It explicity does not say "when you add any content". Most statements in Wikipedia are not specifically cited, even in the articles that are the best-cited we have (e.g., Featured Articles). So long as the content isn't original research, the patently-obvious example of Wikipedia (or any other MediaWiki-based site) as a revision control environment shouldn't need a lot of citations, and we ought to be able to come up with a few to make it acceptable. RossPatterson 23:07, 4 July 2007 (UTC)
I would not delete an unsourced mention of Wikipedia as possibly the best-known example of a revision control environment, because I agree with the claim, but someone else might delete it. Wikipedia seems to have a number of editors who delete things on the slightest pretext. Having good solid citations removes one such slight pretext. I'm just recommending to edit defensively. Of course Wikipedia is chock-full of unsourced claims, many of which persist for a long time, but on average the unsourced claims are more vulnerable than the sourced claims. 7,281,588 registered users and an unknown number of unregistered users collectively span a larger sample of belief space than any individual can comprehend or probably even accept; thus it's hard to predict whether a particular unsourced claim will be challenged. I'd guess the only way to know for sure is to throw the claim out there and wait. Similarly, the avoid self-references guideline seems to be complex enough to defy one single, universally understood interpretation. Just because you and I understand it to mean something doesn't mean all the other 7,281,588 do too. What a guideline actually means has less influence on an article's evolution than how the people who edit the article happen to interpret the guideline. Thus I recommend being extra-careful when mentioning Wikipedia or other Wikimedia Foundation wikis in an article not primarily about them. (Personally, I find the avoid self-references guideline somewhat curious, even silly; if someone else wants to re-use Wikipedia's content outside Wikipedia, I don't see how we are any more obligated to simplify that process for them than any other content provider is obligated to make it simple for us to re-use their content on Wikipedia. But obviously my opinion is irrelevant to that guideline. I follow it simply to avoid wasting my time by making edits that are likely to get deleted, having learned that lesson the hard way.) --Teratornis 01:49, 5 July 2007 (UTC)

[edit] SCM stands for?

SCM is shown as (source) code management. Isn't it Software Configuration Management, based on SEI-CMM or SEI-CMMI? —The preceding unsigned comment was added by 194.39.218.10 (talk) 02:40, 30 May 2007

Software Configuration Management is a (relatively) recent phenomena in Configuration Management. No, SCM isn't based on SEI standards. Those standards may include or reference SCM practices but are orthogonal to them. In particular, most the terms and practices shown existed in some form in the 1960s and 1970s, long before the Capabilities Maturity Models of the 1980s.

Both terms are in common use in online documentation, product advertisements and software engineering textbooks. Bauer's book on Automating UNIX and Linux Administration notes the usage of SCM as meaning Source Code Management while encouraging system administrators to think of configuration files as the 'source code' for the operating system's configuration. The terms seem to imply a competition between management of source code vs. management of configuration files. However, the actual practices cover all project related-files, including those not traditionally thought of as source (e.g. binaries.)

The specialization of CM into SCM is a good example of taking a real world method (CM) with physical objects (blueprints, buildings) and applying them to the virtual world (source code, machine code). In the real world, you can't file a building with your government office, so you file the blueprints and claim the physical building matches what is on the blueprints. In the virtual world we create when we use computers, source code and machine code and configuration files can all be submitted to and retained in version control or submitted for review or forked or patched.

If you want real confusion, look at the definition of Dynamic stream and not tell me that it didn't come from a small market-share, proprietary SCM vendor's documentation for a single tool. If I didn't think I would get immediately reverted, I would rip it out.

--Waveclaw 21:17, 18 June 2007 (UTC)

There aren't enough three letter acronyms to go around. Thus a lot of them, including SCM, have disambiguation pages. --Teratornis 01:53, 5 July 2007 (UTC)

[edit] Enough About BitKeeper!

If nobody protests too strongly, I will remove the whole BitKeeper nonsense. It's totally inappropriate in a general article on Revision Control software. There is a separate article on Free sofware, where the BitKeeper controversy is discussed.

—Bartosz 22:10, 12 June 2007 (UTC)

It seems appropriate to keep BitKeeper in the Distributed revision control section if you're going to keep the other systems. It's certainly uninteresting what's "free" and what's not in this article. RossPatterson 23:29, 12 June 2007 (UTC)
The mention of BitKeeper seems to be short and encyclopedically relevant, to me; i don't think it should be removed. --Piet Delport 11:34, 13 June 2007 (UTC)
BitKeeper was the first distributed system in widespread use, that's why I mentioned it. But the controversy between BitKeeper and the Linux developers, that's just a placeholder for a proper historical summary, which is what the section needs next I think. -- Michael Allan 12:49, 13 June 2007 (UTC)
The references section is quite advertising for particular SCM tools, and while a book may be a reference for a particular toolset, the EE Times news release post from Business Wire is blantant advertising for Subversion. —Preceding unsigned comment added by Vcwizard (talk • contribs) 2007-07-16 13:27:24

[edit] Retitled section: Storage models --> Source management models

The section title was confusing, especially in light of the fact that several modern SCM systems give their users a choice of storage back-ends. For example, subversion gives users an option of either Berkely DB or FSFS storage models.

Also file locking these days is more of a logical concept describing a conflict management strategy. Though it once did refer to the physical locking of file, these days "file" simply means a named unit of source. Once again using subversion as an example, subversion allows "file locking" even when it uses a database as the back end. Egfrank 04:04, 6 August 2007 (UTC)

[edit] "Release" and "development" versions

This article is probably the best one in which to discuss the terms "release version" and "development version". Unfree (talk) 23:28, 25 December 2007 (UTC)

[edit] 1st Citation does not support statement

The citation "^ Rapid Subversion Adoption Validates Enterprise Readiness and Challenges Traditional Software Configuration Management Leaders. EETimes (2007-5-17). Retrieved on 2007-6-1.", does not support the statement "Software tools for revision control are increasingly recognized as being necessary for the organization of multi-developer projects". All the article talks about is the specific uptake of Subversion. As many of these new users will have already been using CVS etc, it does not imply any increase in the recognition of the importance of revision control, just a change of tooling.

I'm not arguing against the statement - with which I agree - just the citation. I think a stronger statement is even possible e.g. "Software tools for revision control are considered essential for the organization of multi-developer projects".

129.215.63.115 (talk) 11:17, 17 April 2008 (UTC)