Talk:Version control

Untitled comments by 68.164.245.150

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)

Not correct, the SCCS history file has all versions of the file available at the same time with the same neglible cost, while RCS declined this by archiving differences relatively to the latest version. This causes RCS to be much slower than SCCS even in the simplest case when retrieving the most recent version. This is caused by the fact that the content of the most recent file in the RCS history file is at an unknown offset after the history list and this history list needs more CPU power to parse than the history list in the SCCS history file. Schily (talk) 15:36, 12 February 2015 (UTC)

Linux kernel claim removal

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"

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

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

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

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

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

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

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

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 Version 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. 48,284,084 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 48,284,084 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?

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!

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

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)

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

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

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

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?

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

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

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

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 (talk • contribs) 12:31, 6 January 2011 (UTC)

CHANGELOG, KNOWNBUGS & TODO files

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?

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)

Control Data computers came with the very powerful UPDATE utility. According to the revision history page of the UPDATE manual, the original printing was (5-71). CDC also had the Modify utility with a release date of (3-8-76). — Preceding unsigned comment added by 73.201.192.113 (talk) 14:25, 31 December 2015 (UTC)

Common vocabulary - Head

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?

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

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 control → Version 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

• See Talk:Version_control#.22Revision.22_vs._.22version.22 above for why version control is increasingly inappropriate for modern tools (i.e. last 5 years). Also the Google Trends like cited here shows how "Version control" is decreasing significantly as a term of use. Andy Dingley (talk) 13:14, 19 May 2014 (UTC)

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

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 control → Revision 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:

• Category:Revision control
• Category:Revision control systems
• Category:Free revision control software
• Category:Proprietary version control systems
• Category:Revision control GUI tools
• Category:Distributed revision control systems
• Category:Software using distributed revision control
• Distributed revision control
• ArX (revision control)
• Vault (revision control system)
• List of revision control software
• Comparison of revision control software
• Branching (revision control)
• Merge (revision control)
• Revision tag
• Repository (revision control)
• Wikipedia:Revision control
• Template:Revision control software

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:

• Distributed revision control#Distributed version control vs. Distributed revision control
• Category talk:Revision control systems#Rename to Version control systems

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

Poll

• support As requested, I restate the obvious for what is now the third time visibly on this page in as many years. Revision control. Andy Dingley (talk) 02:06, 27 May 2014 (UTC)
• support the move to Revision control  Unician ∇  05:59, 27 May 2014 (UTC)

Discussion

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.

Historical consensus at Talk:Version control#"Revision" vs. "version"?! Most of what I see there is disagreement, i.e. a clear lack of consensus! --Joy [shallot] (talk) 08:49, 13 July 2015 (UTC)

See also

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)

Requested move 13 July 2015

The following is a closed 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. It all comes down to sources. Over multiple discussions, those in favor have produced several kinds of literature search, all of which support the move per COMMONNAME. Those opposed mainly offer unsourced anecdotes and claims that times are changing. Maybe they'll prove right in the long run, but in the meantime the sources support the move. RockMagnetist(talk) 23:06, 3 September 2015 (UTC)

---

Revision control → Version control –

• general Google search for software "revision control" gives me About 392,000 results
• Google Books search for software "revision control" minus common fodder - About 982 results - after clicking through the last pages - Page 56 of about 891 results
• general Google search for software "version control" gives me About 1,990,000 results
• Google Books search for software "version control" minus common fodder - About 1,210 results - after clicking through the last pages - Page 75 of about 981 results
• general Google search for software "source control" gives me About 904,000 results
• Google Books search for software "source control" minus common fodder - About 942 results - after clicking through the last pages - Page 52 of about 827 results

The oldest book I found mentioning this was:

• United States National Aeronautics and Space Administration (1962). "version+control" NASA SP. Scientific and Technical Information Office, National Aeronautics and Space Administration [available from National Technical Information Service, Springfield, Va.] p. 47. For software projects, it is routine to use version control for both pre-release and post-release deliverable systems. (ed: likely republished source dating error, please ignore --Joy [shallot] (talk))

For other two terms I couldn't find anything else from the 1960s that was specifically about software - it was interesting to see false positives from electrical engineering documents and later NASA documents that talk of revision control of themselves.

So I'd move the article to that title, because it's a bit more generic, clearly most popular and apparently the oldest, in accordance with WP:AT. -- Joy [shallot] (talk) 08:51, 13 July 2015 (UTC) Relisted. Jenks24 (talk) 15:43, 23 July 2015 (UTC)

• Oppose for all the reasons listed on this talk: page for several years. Andy Dingley (talk) 08:58, 13 July 2015 (UTC)
  • Can you please state some of them, because I was unable to find anything much (other than assertions)? I have tried to do my homework, please do yours. --Joy [shallot] (talk) 09:12, 13 July 2015 (UTC)
    • Read this page Andy Dingley (talk) 09:33, 13 July 2015 (UTC)
      • I have read it, and like I said, I found nothing of substance. I see various assertions that "revision" is more fine-grained than "version". Even if we take that at face value - which isn't necessarily accurate - that is still orthogonal to the idea that the article title need not match any such subtle distinction. The term version control is not only the most common, it is also recognizable, natural, precise, concise and consistent. I see no actual argument that clarifies exactly how the term revision control is more appropriate according to the relevant policies. --Joy [shallot] (talk) 20:26, 13 July 2015 (UTC)
• Comment: User:Schily removed the NASA 1962 document (referenced above) from the article claiming the document is from 2003. I've been unable to see more than the snippets, but the meta data says 1962 in no uncertain terms. I have no intention to start an edit war, this seems like someone is being served incorrect search results. Can someone else verify it? --Joy [shallot] (talk) 09:14, 13 July 2015 (UTC)

If you are unable to verify your claims, we can only follow the text you introduced. This text however leads only to a .doc type document from 2003 that does not mention 1962 at all. Given the fact that SCCS was the first revision control system and appeared in 1972, your claims are non-probable for other reasons as well. Schily (talk) 12:28, 13 July 2015 (UTC)

The link that I pasted says 1962 in two places, as I mentioned above. The only other year I see there is 2006 as the year when it was digitized. I see no mention of 2003, or that it is a .doc file. Where do you see that? I see your point about SCCS, but I wouldn't necessarily presume that version/revision/source control as a concept could not be older than its software implementation. --Joy [shallot] (talk) 20:26, 13 July 2015 (UTC)

Well, the simplest way of searching: [5] gives you a document updated in October 2003. Our discussion makes it the second, but it was the first hit yesterday. Nothing leads to 1962. Schily (talk) 09:42, 14 July 2015 (UTC)

Looks like the only other document independently archived as a whole is NASA-SP-6102 from 1993 at archive.org? Either way, looks like the meta data in my original Google Books search is invalid, I'm crossing it out. --Joy [shallot] (talk) 15:49, 15 July 2015 (UTC)

Sometimes google's book snippets are useful; this one is only useful for finding the actual source. The document is the NASA Systems Engineering Handbook, published in 1995 and revised in 2007, 2010. There was no revision or other republication in 2003; likewise it is unlikely that it would have been a ".doc" (all of the copies I find are PDFs). NTRL lists only those dates, and suggests you buy a copy. However there are accessible copies of these online: 1995, 2007. Neither contains "1962" (which is the only factual part of Schily's comments). There was a draft version of the document in 1992. TEDickey (talk) 23:23, 13 July 2015 (UTC)

Wrong claims as usual. Schily (talk) 09:44, 14 July 2015 (UTC)

Your ".doc" link is not the original document. See Jim Helm's CV, which demonstrates that he worked on contracts for NASA in more than one company, but was not the author of the document (otherwise it would be listed in the CV). Rather, he has had some use for it in an academic environment. The 2003 date is simply when last edited (for whatever reason -- perhaps as a contributor toward the 2007 revision). An original document would of course be from the government agencies which maintain and provide it. TEDickey (talk) 00:44, 15 July 2015 (UTC)

The ".doc" also is only (at most) a portion of the original document, since it lacks the title page, figures, etc., and is about 40% of the total page count. Perhaps you can make a nice story explaining these discrepancies, but it does not appear possible to contrive one which makes it into a reliable source with known authorship and publication date TEDickey (talk) 01:07, 15 July 2015 (UTC)

Either way, let's close this off topic discussion. If it's not from the 60s but from the 90s, it's no longer the oldest, and the notion is moot. I need to dig through further, I'll do it as soon as I find some more time. In any event, the move proposal does not necessarily center on the issue of age, rather, it is based on all the other naming criteria. --Joy [shallot] (talk) 15:49, 15 July 2015 (UTC)

I'd still oppose the move. COMMONNAME doesn't prioritise "the oldest name" (which would be "change control" anyway, and that was applied in the card deck era). However in modern use, especially around distributed systems like Git, the only form of the name that still makes complete sense is revision control, rather than version control. As there is otherwise little to choose between then (for the Subversion / CVS era either would be equally good), then we should favour the current name of revision control. Andy Dingley (talk) 19:38, 15 July 2015 (UTC)

Sure, git calls the basic commit elements revisions, but it's also widely used to publish versions of software, what with all the various sorts of tags and branches and whatnot. The term version control seems to me as current as revision control, I fail to see how it being significantly more common in any way indicates that it's less current. I clicked the Google Trends link in the discussion above and the trend line with a slightly downward trend means nothing when the other trend line also has such a trend. I'm trying to be susceptible to a precision argument, but I'm just not seeing it elaborated here. How exactly is "revision control" more current and more-completely-sensical than "version control"? --Joy [shallot] (talk) 08:44, 17 July 2015 (UTC)

You just don't understand git, do you? Without realising the changes in the latest generation of distributed source control tools, i.e. from Subversion to Mercurial / Git / Monotone, it's impossible to even understand the question, let alone choose the answer. Andy Dingley (talk) 09:28, 17 July 2015 (UTC)

Joy asked a question, and rather than explain (or point to a knowledgeable explanation), you gave a non-constructive answer. TEDickey (talk) 20:44, 17 July 2015 (UTC)

They've wasted enough time for both of us already. Competence is required. This extends to learning something about the current state of the art in a topic before suggesting renaming it. Andy Dingley (talk) 21:14, 17 July 2015 (UTC)

Your assertions continue to be devoid of references to relevant naming or at least actual reasoning. I'm already informed about the current state of the art in the topic and I see no inherent explanation in the said state of the art of why we would need to go contrary to WP:AT. I'm going to go out on a limb and assume that you have a point, and look up some relevant documentation - let's start with the first book about git that their official docs point to:

https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control

1.1 Getting Started - About Version Control

This chapter will be about getting started with Git. We will begin by explaining some background on version control tools, then move on to how to get Git running on your system and finally how to get it set up to start working with. At the end of this chapter you should understand why Git is around, why you should use it and you should be all set up to do so.

About Version Control

What is “version control”, and why should you care? Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. [...]

So, you were saying something? --Joy [shallot] (talk) 10:28, 18 July 2015 (UTC)

And, to be extra fair, let's mention that in the same vein, the respective official docs say Mercurial is a "version control system", monotone is a "version control system", Bazaar is a "version control system", Subversion is a "version control system", CVS is a "version control system". I did also quickly find that the Mercurial book uses the phrase revision control, but it was clearly in the minority. With the real-world consensus this strong, and your attitude so bad, this is a very depressing conversation. --Joy [shallot] (talk) 10:38, 18 July 2015 (UTC)

There is a UNIX command "vc" (version control), see [6] and the SCCS man pages include the term "version" many times, but not a single "revision" appears in the SCCS man pages. It seems that "revision control" is mainly related to RCS. All recent implementations of such systems are based on the ideas of the distributed development SCCS enhancements that appeared in early 1986 (NSE - Network Software Engineering) and later systems such as Teamware and BK-SCCS. Schily (talk) 12:51, 20 July 2015 (UTC)

During previous discussion, you were unable to provide a reliable source for any part of this comment. You need not repeat it, since that does not increase its veracity. TEDickey (talk) 00:14, 21 July 2015 (UTC)

You seem to be confused as I of course did give a reliable source - I recommend you to read the man pages I mentioned. It is you who never verifies claims with reliable sources, so stop your attempts to waste other people's time and if you are able to give a reliable source for a different distributed version control before early 1986, you are welcome again. Schily (talk) 09:26, 21 July 2015 (UTC)

SCCS isn't a distributed version or revision control system. You are confused between a system that allows distributed access to a single central repository (as was later grafted onto SCCS) and a system with truly distributed multiple repositories as equal peers. SCCS is antediluvian. As has been the point all along here, the terms "change", "version" and "revision" have all been used over the years, but for the current environment where distribution (i.e. Git-like) is so crucial, "revision" becomes favoured. Andy Dingley (talk) 10:31, 21 July 2015 (UTC)

It seems that you are not informed about version control in general and SCCS in special. The first distributed systems have been build on top of SCCS using NFS as a sharing mechanism. This happened first with NSE in early 1986 and later with TeamWare. CVS appeared later than NSE and TeamWare. BitKeeper SCCS was derived from the ideas behind the SCCS based systems and Larry McVoy was a co-developer of such an SCCS based system (TeamWare) before he become self employed and started the BK project. As all modern systems are derived from BK, they are indiretly derived from SCCS. BTW: RCS, CVS and SVN are antediluvian, if you are searching for outdated systems. SCCS on the other side still is the fastest version control system an will soon come with a TCP/IP based networking interface for distributed development. Schily (talk) 11:46, 21 July 2015 (UTC)

SCCS only uses a single repository. Even if access to this repository is shared, it is shared at the file level (pre-web) or via a presentation layer running on a single server (post-web). However the backend repository remains a singleton. This is not the case with the current generation of truly distributed systems that operate multiple peer repositories and can share revisions between them. Andy Dingley (talk) 14:36, 21 July 2015 (UTC)

Instead of claiming things that do not stand a review, I recommend you to read the documentation for TeamWare before you continue to write things that do not apply to the information I send you. NSE allowed you to NFS mount the central repository and to mount your local modifications inside a tfs (translucent filesystem) on top of that NFS mounted central repository - note this was in 1986 when disk space was tight! TeamWare has "bringover" to create a fully local copy without a need to have the SunOS-only TFS, so AT&T, IBM and HP could use TeamWare for the collaborative CDE development. It seems the world evolved long before you learned UNIX and what you learned seems to be biased by people who have no clue on what exists before CVS was created. Distributed development does not require the non-coordinated development model that github caused. It is based on the ability to work locally and later decide what to do with the result. This is not possible with the CVS based idea but with TeamWare and software created after the TeamWare model. Schily (talk) 15:40, 21 July 2015 (UTC)

I would refer you to my previous statement: [7] Andy Dingley (talk) 15:51, 21 July 2015 (UTC)

If you believe that SVN is a distributed system, you may be in a different world than I am. Schily (talk) 15:39, 22 July 2015 (UTC)

What part of "the changes in the latest generation of distributed source control tools, i.e. from Subversion to... " did you have the trouble with? Andy Dingley (talk) 15:54, 22 July 2015 (UTC)

You still miss-interpret history. SVN is not a precursor of modern systems, it is a dead end from the superfluous development line: RCS -> CVS -> SVN. The antecedence for modern systems is: SCCS(1972) -> SCCSv4 -> NSE -> TeamWare -> Bk-SCCS -> { Mercurial | Git | SCCSv6 }. Schily (talk) 16:36, 22 July 2015 (UTC)

And what relevance would that have to anything? The question here remains whether "version control" (implying "the version" as the crucial aspect) is a better article title than the current "revision control", where the advent of distributed change control systems (which neither SCCS nor Subversion are) mean that "the revision" (i.e. the change, not the static image) has become the more crucial. Andy Dingley (talk) 16:48, 22 July 2015 (UTC)

You again show us that yo don't know about the historic facts and that you are trying to judge based on irrelevant details. The term revision was introduced by RCS and it turns out that systems based on the RCS ideas (RCS, CVS, SVN) are more or less dead now while systems based on the SCCS development line are still in use. Schily (talk) 09:52, 23 July 2015 (UTC)

You seem very fond of SCCS. Now it's true that the Bitkeeper route means that some details of how to store file histories inside a history file are in current use today and they trace their history as a file format back through SCCS. Yet what difference does that make to users today, or to the naming of this article?

The important thing is what these systems do, as use cases that are visible to the outside world (and the internal file format isn't). Around 5 years ago there was a shift from centralised server-based systems with distributed client access and atomic commits across multiple files (Subversion as an exemplar) to a range of new systems that offered truly distributed repositories and avoided the limitation of a single canonical trunk (Monotone / Mercurial / Git). This was a significant change, much as the change to atomic commits had been, much as the change from file management to fileset management had been, much as the switch from filesystem sharing to server facades had been. This latest change was also one that made the notion of "version" unworkable as (with multiple repositories and multiple trunks of equal status) and encouraged a shift to thinking more about "revisions" instead, as the unit of change management. That is the key to naming this article appropriately, and why the current name at revision control is better than a shift to version control. Andy Dingley (talk) 10:24, 23 July 2015 (UTC)

But the claim that the notion of "version" is 'unworkable' is your personal inference that is unsupported by references. Let alone the further inference that this notion somehow makes the most common name for the concept - "version control" - unworkable. We literally have the docs for all current systems using the specific phrase "version control" and "version control system" for these concepts, and I haven't seen any of them with annotations there saying anything to the effect of "we're sorry to still be using an obsolete/old/unworkable/whatever term". --Joy [shallot] (talk) 12:24, 23 July 2015 (UTC)

So you agree that "docs for current systems" should be of influence, rather than tying things back to our own favourite piece of the '70s, as Jörg keeps wanting to. Interesting.

So take a look at the Mercurial intro guide: http://hgbook.red-bean.com/read/a-tour-of-mercurial-the-basics.html Do you see "version" used there? Or revision? Andy Dingley (talk) 13:01, 23 July 2015 (UTC)

This is from 2009..... Look at a recent sccs man page: [8] and it's SEE ALSO references. This is from January 2015 and does not include "revision" at all, but "version" all over the text. Schily (talk) 16:48, 23 July 2015 (UTC)

What ongoing relevance does SCCS have for anyone these days, other than yourself? Andy Dingley (talk) 17:14, 23 July 2015 (UTC)

I already mentioned that. How does one Mercurial book trump everything else (including Mercurial own website)? Google Trends indicates that Mercurial's prime has long passed, and even then it was a shadow of git and svn. This is really grasping for straws. --Joy [shallot] (talk) 18:50, 23 July 2015 (UTC)

When you looked at Google Trends, did you happen to notice what Google describe both Git and Mercurial as? Revision Control, not Version. Andy Dingley (talk) 19:59, 23 July 2015 (UTC)

Google in and of itself isn't a reliable source on that topic, regardless of the fact its search results are indicative of various aspects of popularity. For all we know, it could be using Wikipedia as its source for that particular subtitle. --Joy [shallot] (talk) 19:18, 24 July 2015 (UTC)

Google is well known for using WP... BTW: it is also well known that Wikipedia is not a reliable source and that sometimes even circle citations are used to verify false claims. See the "invention" of the first name "Wilhelm" as the tenth first name for Karl Theodor Maria Nikolaus Johann Jakob Philipp Franz Joseph Sylvester Freiherr von und zu Guttenberg by a Wikipedia author that first caused "Der Spiegel" to copy that false claim and later let Wikipedia add "Der Spiegel" as a reference and "reliable source" for the correctness of the first name "Wilhhelm" Schily (talk) 09:51, 27 July 2015 (UTC)

It makes absolutely no sense to squabble about the title of the article based on the detailed characteristics of various source code or document control, version, or revision systems. These terms, and others, have all been used in the >60-year history of the subject matter. What today is the common name, by WP criteria, may be argued but I doubt a clear candidate will emerge, as the article doesn't seem to define one particular applications area, with the exception that it seems focussed on software systems that serve as databases of revision history of digital code, not historical archives of physical documents. Such revision control software systems came into existence, I think, when large software systems were developed with stringent quality control for military applications, such as the ballistic missile defense systems in the 1960s, that I believe were primarily developed by Bell Labs and Western Electric, from which SCCS emerged, I think. But this article is silent about the history of the subject matter. Rather than squabbling about titles, perhaps editors should rather bother to discover the history of the subject matter, and then decide what the best title might be. The article quickly looses itself in details that seem disorganized and inappropriate. Kbrose (talk) 16:03, 21 July 2015 (UTC)

What do you mean you doubt a clear candidate will emerge? Read the proposal and see the numbers - they could hardly be any clearer than that. The squabble only seems to exist because one particular user (Andy) has apparently decided that "revision" is somehow favoured, but they have provided no clear argument for that claim. --Joy [shallot] (talk) 17:39, 21 July 2015 (UTC)

They don't really appear until the 1970s, when large online mass storage becomes more available. This is concurrent with early work that led to Unix. Plauger & Kernighan's Software Tools (in Fortran / Pascal / C) book gives a look into this period: lots of algorithms for handling the sort of deltas needed for this work.

Before that, and with the reliability-critical aerospace systems, it was largely about card decks and thinking of "change control". Complete snapshots were duplicated and mechanically filed. Andy Dingley (talk) 16:18, 22 July 2015 (UTC)

• I see no evidence having been presented that "revision control", contra "version control", is somehow nuanced. Alakzi (talk) 10:33, 6 August 2015 (UTC)
  • Can you explain what this comment means with regard to the move proposal? --Joy [shallot] (talk) 20:05, 6 August 2015 (UTC)

• Support. Checking, the websites of subversion, CVS, git, & Perforce all use "version control" to describe themselves. Seems pretty clear cut. Mercurial's website calls itself "source control" which is a null push. If all the biggest and most important entities of this article's topic call themselves version control, Wikipedia should follow them. SnowFire (talk) 17:39, 6 August 2015 (UTC)

• Oppose. Renaming accomplishes nothing. Editors would be better advised to improve content than waste time on administrative cosmetics. Kbrose (talk) 21:39, 8 August 2015 (UTC)
  • You've made the same claim above, but haven't responded to my earlier question contesting it. Have you read WP:COMMONNAME, the Wikipedia policy about using commonly recognizable names? --Joy [shallot] (talk) 12:02, 9 August 2015 (UTC)

• Support - In addition to being the more common name, version is more generic the revision. Not all version control systems limit themselves to just dealing with revisions to flles, but also handle completely different versions. For example consider systems that allow storing of binary blobs ( such as ClearCase element types of binary_file ), in addition to storing text files with revisions ( example ClearCase example of compressed_text_files or text_file elements ). PaleAqua (talk) 14:44, 13 August 2015 (UTC)

• Comment to closer, since this one seems to have been open forever. I recommend taking a look at List of revision control software, and see what everybody can indisputably agree are examples of the topic of this article call themselves. It's usually "version control" and occasionally "source control." Combined with the n-grams from the nominator, I feel this is a strong real-world evidence based argument, which should in my opinion take priority over theoretical "it should really be called THIS" concerns. ( http://www.perforce.com/ , http://www.nongnu.org/cvs/ , https://subversion.apache.org/ , https://git-scm.com/ , etc.) SnowFire (talk) 04:00, 20 August 2015 (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.

No consensus for move

I see no consensus for the performed move. Kbrose (talk) 23:41, 3 September 2015 (UTC)

I am an admin and my decision about consensus was based on the quality of the arguments, as I summarized in the previous section. RockMagnetist(talk) 23:58, 3 September 2015 (UTC)

I do agree with one point you made earlier. This issue is really not worth all these debates. Your time would be much better spent improving articles. RockMagnetist(talk) 02:31, 4 September 2015 (UTC)

This is the third time you've posted something here that doesn't actually contribute to the building of consensus. --Joy [shallot] (talk) 18:46, 28 September 2015 (UTC)

History

Would be good to have a history section. All the best: Rich Farmbrough, 09:46, 25 May 2017 (UTC).

Version control vs. version control system

In software engineering, version control is a class of systems responsible for managing changes to...

Nope. That's a version control system or tool. Version control is the act of controlling versions of files.

The overview section needs a re-write. It's very detailed; hardly an overview

"Centralized revision control systems solve this problem in one of two different "source management models": file locking and version merging." and then there are four things listed!?!?

I'll get back to this... Stevebroshar (talk) 02:28, 8 May 2024 (UTC)