Talk:Revision control

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computer science (Rated B-class, High-importance)
WikiProject icon This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
B-Class article B  This article has been rated as B-Class on the project's quality scale.
 High  This article has been rated as High-importance on the project's importance scale.
 

Untitled comments by 68.164.245.150[edit]

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)

Linux kernel claim removal[edit]

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)

Note that the Linux Kernel stared in 1991. Some core developers were using CVS as of September 1997; although, Linus Torvalds himself did not use it, so it was not official. Linus did not himself use a version control system until the Linux Kernel until he chose BitKeeper in February 2002. That was less than 7 years ago, so it's kind of subjective if you consider that "recently". But you can say that Linux had no official, project-wide version control system for more than half of the life of the project. It was 2002-02-05 linux-2.5.4-pre1 where BitKeeper was first officially adopted and then it was 2005-06-17 Linux 2.6.12 where git became the official version control system of Linux. See Linix kernel Revision Control. --68.164.245.150 (talk) 03:22, 13 November 2008 (UTC)

"Revision" vs. "version"[edit]

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".

I think favoring "Revision" over "Version" is wrong. The canonical name should be "Version Control", so the article name should be moved and the redirection should be from "Revision Control" to "Version Control". Wikipedia's category is even Category:Version_control. Obviously, the terminology is sloppy and one is not more correct than the other; however, I think it is reasonable to choose the terminology that is in most common use. In other words, pick the title that a user is most likely to type in the Wikipedia 'search' box. It is easy to show that "Version Control" should be the canonical name based on it being the most commonly used.
This Google Trends report comparing search phase "revision control" to "version control" shows that the phrase "version control" is referenced nearly 13 times as often as the phrase "revision control". Google_Trends shows the relative search volume index for the two phrases over 4 years as "revision control": 1.00 and "version control": 12.8"
The ACM Portal web site search shows only 242 citations for "Revision Control" and 1179 citations for "Version Control" (nearly 5 times as many).
The ACM's Portal web site has a Computing Classification System (CCS) for publications. Their primary classification index for this category is D. Software, D.2 SOFTWARE ENGINEERING, D.2.7 Distribution, Maintenance, and Enhancement, Subjects: Version control. There is none for "revision control". Finally, if you search by keyword, they have a special subject keyword of Subject "Version control", but no subject keyword defined for Subject "Revision control".
The International Software Testing Qualifications Board web site has a publication, ISTQB Standard Glossary of Terms used in Software Testing V.2.0, Dec, 2nd 2007, that has a definition for "version control" while it does not have one for "revision control".
The IEEE has an entire site dedicated for their Software and Systems Engineering Vocabulary Database (SEVOCAB). Search the SEVOCAB for "revision control" and you get 0 results. Search for "version control" and you get 6 results, with the top definition from an IEEE publication (cited from an ISO publication), ISO/IEC FCD 24765 Systems and software engineering vocabulary which gives the definition for "version control" given as:
version control. (1) establishment and maintenance of baselines and the identification and control of changes to baselines that make it possible to return to the previous baseline (ISO/IEC 24765:2008 Systems and software engineering vocabulary)
The IEEE SEVOCAB gives no definitions for "revision control"...
--Noah (talk) 22:24, 12 November 2008 (UTC)
well, someone ignored all of the discussion and renamed the category anyway. Tedickey (talk) 19:09, 19 July 2009 (UTC)
I would like to rename all the 'Revision control' articles to 'Version control'. I still need to do a complete review of the text of the articles, but my initial thought is that the term 'revision control' can still be used as an alternative, but the main term is 'version control'. I think RCS may have introduced 'revision control' because at the time (1982) many mainstream file-systems supported 'versions' and Unix didn't offer such a file-system. The capability to retain 'versions' in the older file-systems was really only useful for a single user, and so it's easy to imagine the folks who developed SCCS and RCS didn't want to their solutions to be associated with the processes for 'version control' in those older systems. JWBito (talk) 04:30, 3 May 2010 (UTC)


I agree. I think calling this revision control is WRONG. I've never heard these version control systems systems, being called revision control system, at all, never and I work in the industry. Its a falsehood and needs to be corrected.

scope_creep (talk) 22:55, 22 Aug 2011 (UTC)

Wikipedia:The Truth TEDickey (talk) 22:06, 22 August 2011 (UTC)
I find it strange that someone "who works in the industry" can claim to have not heard either of these terms. Rightly or wrongly, a vast number of terms are used to refer to the same function (there's "source control" andd "change control" too) and these are two of the more common.
As to their rightness, then it's difficult to distinguish between the two for products up to Subversion and the like. However the more recent generation of distributed products, such as Mercurial, Git or Monotone do make a difference. In a distributed system it becomes impractical to refer to a "version" as such - the current state of a version would depend upon which repository you're looking at, and whether other repositories' changes have been merged to it. In these cases, the term "revision control" is not only appropriate and current, but it becomes the only term (of these two) that is still applicable. Mercury (et al) work by managing "change sets" rather than "versions". Andy Dingley (talk) 14:51, 23 August 2011 (UTC)

version number systems[edit]

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.

Marketing Pitch[edit]

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)

The McCabe advertising is back. Shouldn't that be removed again? —Preceding unsigned comment added by 130.138.227.41 (talk) 11:02, 4 June 2009 (UTC)

Atomicity[edit]

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)

cleanup[edit]

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)

Distributed revision control[edit]

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.

Redux[edit]

...or, New Matter: Why does this paradigm deserve a lengthy section in this article, where the alternative remains completely un-mentioned? "Distributed la la la" already has it's own article, as does "Client-server", though not WRT version control specifically. Can we please honor Once and only once and get this article in good shape to represent the subject overall? "Distributed..." deserves a brief mention as a recent update to toe state ofnthe art, but, the current article leaves the impression that client-server VCS is obsolete. --76.102.243.117 (talk) 22:12, 5 June 2010 (UTC)

I want to quibble on the word "recent". In my opinion, in computing "recent" suggests to the reader that it is something released in the last few months or last couple of years at most - DVCSs are quite a bit older than that, as you can see by looking at the date stamps above you! Thanks partly to the advent of git, DVCS's have become wildly popular, too - just look at the number of repositories on Github. So it's neither recent nor obscure.--greenrd (talk) 18:44, 26 August 2010 (UTC)

Lay Uses[edit]

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. 22,319,507 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 22,319,507 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)

SCM stands for?[edit]

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)
The term "software configuration management" is often used as a synonym for "source control" but my understanding is that this usage is incorrect. Software configuration management is a much wider subject of which source control only forms one part: it also includes such aspects as work item tracking, testing, change management, deployment, upgrade and release process, and so on. 194.60.38.10 (talk) 12:18, 3 November 2010 (UTC)
Exactly! The first line that says revision control is also known as SCM is wrong and should be fixed. 124.149.187.254 (talk) 12:31, 1 December 2010 (UTC)

Enough About BitKeeper![edit]

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 (talkcontribs) 2007-07-16 13:27:24

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

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)

"Release" and "development" versions[edit]

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)

No, that is a different aspect of SCM (software configuration management). Revision control is more about tracking changes over time. 124.149.187.254 (talk) 12:37, 1 December 2010 (UTC)

1st Citation does not support statement[edit]

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)

POV notice[edit]

Something is really odd in this article. There is no mention of Subversion, except for two documents indirectly cited in references, despite its popularity. There is also only a single indirect mention of CVS. It is hard to imagine how an article about revision control barely mentions the two mostly used revision control systems currently.

On the other hand, there is a list of distributed revision control software, including some little-known ones, even though they have their own article.

--Juliano (T) 18:09, 9 July 2008 (UTC)


Common Vocabulary?[edit]

Shouldn't "common vocabulary" be "glossary?" DEddy (talk) 01:01, 21 April 2009 (UTC)

Dunno. I think "common vocabulary" might be better because it implies that these definitions are a bit more subjective (idiomatic?) than you'd expect to find in a glossary. And that's as it should be. It seems that so many version control terms are poorly thought up and/or misappropriated, by commercial vendors and OS projects alike. It would be incorrect to imply that there is a single glossary that applies to all documentation thereof. Tue18nov (talk) 18:43, 21 April 2009 (UTC)

Shouldn't these words be added – “push” and “pull” here (i mean to the Common Vocab)? I've seen them used many times (by gits) and once in the article, without any explanation. Actually, it's one of the reasons i came here, to find out! 174.6.76.165 (talk) 19:55, 7 November 2012 (UTC)

MS Windows system restore points[edit]

I just reverted a claim that 'system restore points' in MS Windows are an example of a Revision Control system. I think this is pushing the point too far, in relation to the kind of revision control systems discussed elsewhere in the article. It may be an example of Backup and Restore, but I think it is a kind of WP:OR by synthesis to make the claim I reverted. If there are citable references somewhere that this has been discussed or referred to as 'revision control' by knowledgeable, independent, published authors, then I'd like to look into it. --Nigelj (talk) 17:00, 12 May 2009 (UTC)

Example diagram[edit]

In the example diagram of a project history, the merges at revisions 4 and 9 are not actually merges. There would need to be merges between revisions 1 and 4, but parallel to revisions 2 and 3. In VCSes like Git, this type of history would be collapsed so the merge would be invisible, and you would not see any branching. Pesto (talk) 16:48, 26 August 2010 (UTC)

Revision numbering vs. checksums and the like[edit]

The first paragraph mentions revision identifiers: "Changes are usually identified by a number or letter code". DVCSes obviously don't use sequential IDs, so that's one reason to remove or change that part. Another is that this is an implementation detail which does not belong in an introductory sentence. The accompanying diagram probably doesn't need to be changed, since in this simple case numbers are probably the easiest way to keep revisions apart. — Preceding unsigned comment added by Engmark (talkcontribs) 12:31, 6 January 2011 (UTC)

CHANGELOG, KNOWNBUGS & TODO files[edit]

Are CHANGELOG, KNOWNBUGS & TODO files related to this subject?

Also, the use of notes in the top of each code, about its changes, and the use of graphs (UML) for management of the procedures and classes which the software is made of. Galzigler (talk) 13:10, 28 February 2012 (UTC)

Yes, but these would be considered obsolete practices.
In the old days, revision control was done by manual use of computers. There were files that recorded the issues you describe, but they did this by humans manually maintaining these lists by typing into text files. There would also be a changelog, with reasons, related bugs and change authors, at the top of each source file. These practices began in the 1980s, with the start of access to "large", "cheap" storage on hard disks.
Nowadays revision control is done by automated revision control systems (read the articles for more). There is no need for a CHANGELOG file, for embedded log comments within a source file, or for files listing the sets of files needed to build a product. KNOWNBUGS and TODO are handled instead by a database and something like Buzilla or Jira. These automatic computer processes are no human effort to record and they are more accurate. In a good programming shop, it should be a hanging offence to still persist in recording this stuff manually. Despite that, many shops still keep doing it - often the older team, like SQL developers, keep doing it whilst the more up to date Java coders in the same office use their computers to do this for them instead.
UML is for design problems, and quite a different topic. Andy Dingley (talk) 13:54, 28 February 2012 (UTC)
As much as I know UML is a way of designing a program before actually building its source code. About ChangeLog, ToDo and KnownBugs files - I still see it's in use by programmers that publish their open-source softwares over the web. Maybe, as being a part of the history of this subject, it should be added to the article, or in a seperated article dealing with the history of it. I saw that there is an article about ChangeLog, and a section in some other article about ToDo. Galzigler (talk) 15:55, 28 February 2012 (UTC)

History?[edit]

I'd like to know a little more about the history, particularly when various software systems were first introduced and how they've been adopted (and abandoned). Can anyone contribute anything on this? Thanks sprocketonline (talk) 13:32, 16 July 2012 (UTC)

Common vocabulary - Head[edit]

Description of HEAD/Head (Common vocabulary) is not accurate for Git, see e.g. [2]. "The trunk and each branch have their own head ..." vs. "You can think of the HEAD as the "current branch". When you switch branches with git checkout, the HEAD revision changes to point to the tip of the new branch." --mj41 (talk) 11:06, 24 March 2013 (UTC)

No atomic commits in CVS?[edit]

In the section Atomic operations it says: "Not all revision control systems have atomic commits; notably, the widely used CVS lacks this feature." That is doubtful.

Commits in CVS are atomic in the sense that they either succeed completely -- or fail completely and then noting has happened (barred machine crashes). Updates are atomic in the sense that they always run to completion, but they may signal conflicts.

I think the sentence should be removed, or be rewritten to include the proviso about machine crashes.

Dick Grune (talk) 12:23, 10 April 2013 (UTC)

No, the lack of atomic commit in CVS is significant and has been cited by the Subversion developers as the inspiring cause for why they developed svn, as "CVS with atomic commits".
The confusion is not over atomicity (which is as you describe), but rather the scope of these commits. Early revision control systems, like CVS, managed changes at the file level. Later systems, like svn, worked instead with filesets, based on either lists of files, or on directories and their children. The difference is that these systems offered an atomic commit across multiple files as one operation. It's thus easy to check in or commit the entire set of files associated with a change, taking a system from one consistent state to another and avoiding the problem with CVS that there could be changes for individual files where one file was temporarily incompatible with another, i.e. they couldn't offer a simple atomic commit for the overall system state.
File-based RCS needed labelling or pinning mechanisms on versions, to record the states where the files were considered consistent and buildable. For atomic commits of filesets, these labels can be supplanted by simply recording the revision number of any relevant fileset commit. In most software working practices, commits to the trunk are assumed to only be invoked when the files are thought to be consistent and buildable. In such a case, any svn commit revision can then be exported and built. Such assumptions are a key requirement for continuous integration operation. Andy Dingley (talk) 12:41, 10 April 2013 (UTC)

Requested move[edit]

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: page moved. Andrewa (talk) 12:52, 19 May 2014 (UTC)


Revision controlVersion control – This term is in much more common usage. See Google Trends for an example. Google Books and Google news archive show a similar difference in frequency. Jameshfisher (talk) 11:31, 12 May 2014 (UTC)


The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Post move[edit]

I too oppose renaming to version control as though the term version control has historically been used more revision control is the more general and contemporary concept. 50.53.15.59 (talk) 13:35, 26 May 2014 (UTC)
Then I think you've done the right thing raising a new RM. I hope that my attempt to insert a header below will allow the bot to pick up the correct section of the discussion.
But I don't agree with the revert to the article. [3] It's quite possible that this RM will move the article back, but meantime, the article should conform to WP:LEADSENTENCE. Andrewa (talk) 00:26, 27 May 2014 (UTC)
Yes, but I also do not agree with the way you closed the issue reverting the renaming that happened some time back after having been hotly debated based on just one person's comment about the Google Trend report. That is why I left you a comment. I seriously considered asking for a close investigation (but decided that was premature and perhaps even immature at this point). 50.53.15.59 (talk) 01:02, 27 May 2014 (UTC)
In that case, perhaps (after raising the matter on my talk page) you should have raised a move review instead of the RM. I don't think you'd get support there, I think the close was quite valid, but I could be wrong, and either way one of us would learn something. But now that we have a fresh RM, better just to let that take its course IMO. Andrewa (talk) 03:46, 27 May 2014 (UTC)
@Andy Dingley: Although your view is clear here, I suggest that you also formally record your support (and perhaps even cite this evidence again) at #Requested move 27 May 2014 below. Andrewa (talk) 00:31, 27 May 2014 (UTC)

Requested move 27 May 2014[edit]

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: moved. Jenks24 (talk) 14:37, 6 June 2014 (UTC)



Version controlRevision control – See historical consensus Talk:Version control#"Revision" vs. "version". 50.53.15.59 (talk) 13:38, 26 May 2014 (UTC)

For consistency of naming, if this stays renamed then I am sure the following (and perhaps others) would have to be renamed as well:

As you can see "revision control" is already rather deeply ingrained into Wikipedia. This is yet another reason changing this is a bad idea. 50.53.15.59 (talk) 14:13, 26 May 2014 (UTC)

Here is more historic discussion:

50.53.15.59 (talk) 14:31, 26 May 2014 (UTC)

Poll[edit]

Discussion[edit]

The lede currently [4] (and in blatant violation of WP:LEADSENTENCE as I pointed out above) reads Revision control, also known as version control and source control (and an aspect of software configuration management), is the management of changes to documents, computer programs, large web sites, and other collections of information. Changes are usually identified by a number or letter code, termed the "revision number", "revision level", or simply "revision". For example, an initial set of files is "revision 1". When the first change is made, the resulting set is "revision 2", and so on. Each revision is associated with a timestamp and the person making the change. Revisions can be compared, restored, and with some types of files, merged. With the possible exception of the last sentence this first paragraph all appears to be describing version control as opposed to the more general concept of revision control.

I'm neutral as to which name the article has. Either way, it needs serious work. My suggestion would be that most of the current content is about revision control systems, which is currently a redirect to Revision Control System but should be an article in its own right (or perhaps for the moment redirect here instead with a hatnote to the article on RCS). Once the details of current systems are split out of this article, there can then be a far more layperson-friendly article on revision control and version control, or perhaps even two articles, which is what belongs at this title (or these titles) IMO. Andrewa (talk) 04:26, 27 May 2014 (UTC)

The article text, and most of the discussion that I've sampled, seems to presume that “version control” and “revision control” are synonyms, and that choosing between them is a matter of style, or is a question of which is more trendy this week on Google. Perhaps some of the confusion and disagreement comes from the fact that they are not synonyms. “Revision control” is about sequential instances, where one or more predecessor instances are revised to form one or more successor instances. “Version control” is potentially more general, and includes scenarios of simultaneous parallel instances. Since this article is entirely about sequential instances, the appropriate title is “Revision control”.  Unician   05:59, 27 May 2014 (UTC)
It is important to establish the relationship between the two terms and state it clearly in the article lead. And in view of the confusion among our editors (myself included, I had it the other way around) we should source our definition(s) carefully. Andrewa (talk) 07:05, 27 May 2014 (UTC)
I question the usefulness of having separate version control and revision control articles. Which term is more general, I believe depends on your approach/point of view. It comes down to what constitutes a version and a revision. Dictionaries define version as: "a particular form of something differing in certain respects from an earlier form or other forms of the same type of thing." and "a specific form or variation of something." Whereas revision is defined as: "the action or process of reviewing, editing and amending." and "the action of reconsidering and altering (something) in the light of further evidence." And the etymology of version comes from meanings for "turn" whereas revision comes from meanings for "view" (if such as any bearings on this subject). I disagree that revision control implies sequential. I agree more with iterative. I understand how revise implies some change between versions (and thus in effect revisions) and how versions need not necessarily be between related revisions. However the control aspect implies a methodology for containing and accessing multiple versions/revisions. Since these methodologies/systems have matured from simple version control to more general ways to handle iterative (not necessarily sequential) revisions, one could argue revision control is the more general concept able control general collections of versions and the relationships between such—revisions. On the contrary, a simple collection of versions is simpler and thus more general. So a version is a specific form of something and a revision is a version and its relationships to other versions. This is much in line with similar concepts from the database world where database management systems went from simple to more complex with relationships to applying concepts from ontology engineering. 50.53.15.59 (talk) 12:29, 30 May 2014 (UTC)

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

See also[edit]

http://www.ltssac.org/articles/inspector.htm for any who haven't seen it and/or think it's a new problem... (;-> Andrewa (talk) 04:21, 27 May 2014 (UTC)