Talk:Version control

message: 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)
replies: text: 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)
thread_title:  Untitled comments by 68.164.245.150 

message: 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)
replies: text: 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)
thread_title:  Linux kernel claim removal 

message: 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)
thread_title:  version number systems 

message: 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)
thread_title: Marketing Pitch

message: 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)
replies: text:  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)
thread_title:  Atomicity 

message: see WP:CONTEXT. This article was targetted by a user targetting several other pages and overlinked it . 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)
thread_title:  cleanup 

message: ...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)
replies: text: 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)
thread_title: Redux

message: 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)
replies: text: 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 , 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)
replies: text:  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)
replies: text: 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.  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  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)
thread_title:  Lay Uses 

message: 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)
replies: text: 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)

text: 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)
replies: text:  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)
thread_title:  SCM stands for? 

message: 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)
thread_title:  Retitled section: Storage models --> Source management models 

message: 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)
replies: text: 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)
thread_title: "Release" and "development" versions

message: 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)
thread_title:  1st Citation does not support statement 

message: 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)
thread_title:  POV notice 

message: Shouldn't "common vocabulary" be "glossary?"  DEddy (talk) 01:01, 21 April 2009 (UTC)
replies: text: 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)
thread_title:  Common Vocabulary? 

message: 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)
thread_title:  MS Windows system restore points 

message: 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)
thread_title: Example diagram

message: 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)
thread_title:  Revision numbering vs. checksums and the like 

message: 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)
thread_title:  History? 

message: Description of HEAD/Head (Common vocabulary) is not accurate for Git, see e.g. . "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)
thread_title:  Common vocabulary - Head 

message: * 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)
thread_title: Poll

message: 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)
thread_title:  See also 

message: I see no consensus for the performed move. Kbrose (talk) 23:41, 3 September 2015 (UTC)
replies: text: 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)

text: 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)

text: 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)
thread_title: No consensus for move

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

message: 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)
thread_title:  Version control vs. version control system