Contents 1 Overview 2 History 3 Structure 3.1 Graph structure 4 Specialized strategies 5 Source-management models 5.1 Atomic operations 5.2 File locking 5.3 Version merging 5.4 Baselines, labels and tags 6 Distributed revision control 7 Integration 8 Common vocabulary 9 See also 10 Notes 11 References 12 Bibliography 13 External links

Overview[edit] In computer software engineering, revision control is any kind of practice that tracks and provides control over changes to source code. Software developers sometimes use revision control software to maintain documentation and configuration files as well as source code. As teams design, develop and deploy software, it is common for multiple versions of the same software to be deployed in different sites and for the software's developers to be working simultaneously on updates. Bugs or features of the software are often only present in certain versions (because of the fixing of some problems and the introduction of others as the program develops). Therefore, for the purposes of locating and fixing bugs, it is vitally important to be able to retrieve and run different versions of the software to determine in which version(s) the problem occurs. It may also be necessary to develop two versions of the software concurrently: for instance, where one version has bugs fixed, but no new features (branch), while the other version is where new features are worked on (trunk). At the simplest level, developers could simply retain multiple copies of the different versions of the program, and label them appropriately. This simple approach has been used in many large software projects. While this method can work, it is inefficient as many near-identical copies of the program have to be maintained. This requires a lot of self-discipline on the part of developers and often leads to mistakes. Since the code base is the same, it also requires granting read-write-execute permission to a set of developers, and this adds the pressure of someone managing permissions so that the code base is not compromised, which adds more complexity. Consequently, systems to automate some or all of the revision control process have been developed. This ensures that the majority of management of version control steps is hidden behind the scenes. Moreover, in software development, legal and business practice and other environments, it has become increasingly common for a single document or snippet of code to be edited by a team, the members of which may be geographically dispersed and may pursue different and even contrary interests. Sophisticated revision control that tracks and accounts for ownership of changes to documents and code may be extremely helpful or even indispensable in such situations. Revision control may also track changes to configuration files, such as those typically stored in /etc or /usr/local/etc on Unix systems. This gives system administrators another way to easily track changes made and a way to roll back to earlier versions should the need arise.

History[edit] This section is empty. You can help by adding to it. (December 2017) See also: Comparison of version control software § History and adoption

Structure[edit] Revision control manages changes to a set of data over time. These changes can be structured in various ways. Often the data is thought of as a collection of many individual items, such as files or documents, and changes to individual files are tracked. This accords with intuitions about separate files but causes problems when identity changes, such as during renaming, splitting or merging of files. Accordingly, some systems, such as git, instead consider changes to the data as a whole, which is less intuitive for simple changes but simplifies more complex changes. When data that is under revision control is modified, after being retrieved by checking out, this is not in general immediately reflected in the revision control system (in the repository), but must instead be checked in or committed. A copy outside revision control is known as a "working copy". As a simple example, when editing a computer file, the data stored in memory by the editing program is the working copy, which is committed by saving. Concretely, one may print out a document, edit it by hand, and only later manually input the changes into a computer and save it. For source code control, the working copy is instead a copy of all files in a particular revision, generally stored locally on the developer's computer;[note 1] in this case saving the file only changes the working copy, and checking into the repository is a separate step. If multiple people are working on a single data set or document, they are implicitly creating branches of the data (in their working copies), and thus issues of merging arise, as discussed below. For simple collaborative document editing, this can be prevented by using file locking or simply avoiding working on the same document that someone else is working on. Revision control systems are often centralized, with a single authoritative data store, the repository, and check-outs and check-ins done with reference to this central repository. Alternatively, in distributed revision control, no single repository is authoritative, and data can be checked out and checked into any repository. When checking into a different repository, this is interpreted as a merge or patch. Graph structure[edit] Example history graph of a revision-controlled project; trunk is in green, branches in yellow, and graph is not a tree due to presence of merges (the red arrows). In terms of graph theory, revisions are generally thought of as a line of development (the trunk) with branches off of this, forming a directed tree, visualized as one or more parallel lines of development (the "mainlines" of the branches) branching off a trunk. In reality the structure is more complicated, forming a directed acyclic graph, but for many purposes "tree with merges" is an adequate approximation. Revisions occur in sequence over time, and thus can be arranged in order, either by revision number or timestamp.[note 2] Revisions are based on past revisions, though it is possible to largely or completely replace an earlier revision, such as "delete all existing text, insert new text". In the simplest case, with no branching or undoing, each revision is based on its immediate predecessor alone, and they form a simple line, with a single latest version, the "HEAD" revision or tip. In graph theory terms, drawing each revision as a point and each "derived revision" relationship as an arrow (conventionally pointing from older to newer, in the same direction as time), this is a linear graph. If there is branching, so multiple future revisions are based on a past revision, or undoing, so a revision can depend on a revision older than its immediate predecessor, then the resulting graph is instead a directed tree (each node can have more than one child), and has multiple tips, corresponding to the revisions without children ("latest revision on each branch").[note 3] In principle the resulting tree need not have a preferred tip ("main" latest revision) – just various different revisions – but in practice one tip is generally identified as HEAD. When a new revision is based on HEAD, it is either identified as the new HEAD, or considered a new branch.[note 4] The list of revisions from the start to HEAD (in graph theory terms, the unique path in the tree, which forms a linear graph as before) is the trunk or mainline.[note 5] Conversely, when a revision can be based on more than one previous revision (when a node can have more than one parent), the resulting process is called a merge, and is one of the most complex aspects of revision control. This most often occurs when changes occur in multiple branches (most often two, but more are possible), which are then merged into a single branch incorporating both changes. If these changes overlap, it may be difficult or impossible to merge, and require manual intervention or rewriting. In the presence of merges, the resulting graph is no longer a tree, as nodes can have multiple parents, but is instead a rooted directed acyclic graph (DAG). The graph is acyclic since parents are always backwards in time, and rooted because there is an oldest version. However, assuming that there is a trunk, merges from branches can be considered as "external" to the tree – the changes in the branch are packaged up as a patch, which is applied to HEAD (of the trunk), creating a new revision without any explicit reference to the branch, and preserving the tree structure. Thus, while the actual relations between versions form a DAG, this can be considered a tree plus merges, and the trunk itself is a line. In distributed revision control, in the presence of multiple repositories these may be based on a single original version (a root of the tree), but there need not be an original root, and thus only a separate root (oldest revision) for each repository, for example, if two people starting working on a project separately. Similarly in the presence of multiple data sets (multiple projects) that exchange data or merge, there isn’t a single root, though for simplicity one may think of one project as primary and the other as secondary, merged into the first with or without its own revision history.

Specialized strategies[edit] Engineering revision control developed from formalized processes based on tracking revisions of early blueprints or bluelines[citation needed]. This system of control implicitly allowed returning to an earlier state of the design, for cases in which an engineering dead-end was reached in the development of the design. A revision table was used to keep track of the changes made. Additionally, the modified areas of the drawing were highlighted using revision clouds. Version control is widespread in business and law. Indeed, "contract redline" and "legal blackline" are some of the earliest forms of revision control,[4] and are still employed in business and law with varying degrees of sophistication. The most sophisticated techniques are beginning to be used for the electronic tracking of changes to CAD files (see product data management), supplanting the "manual" electronic implementation of traditional revision control.[citation needed]

Source-management models[edit] Traditional revision control systems use a centralized model where all the revision control functions take place on a shared server. If two developers try to change the same file at the same time, without some method of managing access the developers may end up overwriting each other's work. Centralized revision control systems solve this problem in one of two different "source management models": file locking and version merging. Atomic operations[edit] Main article: Atomic commit An operation is atomic if the system is left in a consistent state even if the operation is interrupted. The commit operation is usually the most critical in this sense. Commits tell the revision control system to make a group of changes final, and available to all users. Not all revision control systems have atomic commits; notably, CVS lacks this feature. File locking[edit] The simplest method of preventing "concurrent access" problems involves locking files so that only one developer at a time has write access to the central "repository" copies of those files. Once one developer "checks out" a file, others can read that file, but no one else may change that file until that developer "checks in" the updated version (or cancels the checkout). File locking has both merits and drawbacks. It can provide some protection against difficult merge conflicts when a user is making radical changes to many sections of a large file (or group of files). However, if the files are left exclusively locked for too long, other developers may be tempted to bypass the revision control software and change the files locally, leading to more serious problems. Version merging[edit] Main article: Merge (revision control) Most version control systems allow multiple developers to edit the same file at the same time. The first developer to "check in" changes to the central repository always succeeds. The system may provide facilities to merge further changes into the central repository, and preserve the changes from the first developer when other developers check in. Merging two files can be a very delicate operation, and usually possible only if the data structure is simple, as in text files. The result of a merge of two image files might not result in an image file at all. The second developer checking in the code will need to take care with the merge, to make sure that the changes are compatible and that the merge operation does not introduce its own logic errors within the files. These problems limit the availability of automatic or semi-automatic merge operations mainly to simple text-based documents, unless a specific merge plugin is available for the file types. The concept of a reserved edit can provide an optional means to explicitly lock a file for exclusive write access, even when a merging capability exists. Baselines, labels and tags[edit] Most revision control tools will use only one of these similar terms (baseline, label, tag) to refer to the action of identifying a snapshot ("label the project") or the record of the snapshot ("try it with baseline X"). Typically only one of the terms baseline, label, or tag is used in documentation or discussion[citation needed]; they can be considered synonyms. In most projects, some snapshots are more significant than others, such as those used to indicate published releases, branches, or milestones. When both the term baseline and either of label or tag are used together in the same context, label and tag usually refer to the mechanism within the tool of identifying or making the record of the snapshot, and baseline indicates the increased significance of any given label or tag. Most formal discussion of configuration management uses the term baseline.

Distributed revision control[edit] Main article: Distributed version control Distributed revision control systems (DRCS) take a peer-to-peer approach, as opposed to the client-server approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a bona-fide repository.[5] Distributed revision control conducts synchronization by exchanging patches (change-sets) from peer to peer. This results in some important differences from a centralized system: No canonical, reference copy of the codebase exists by default; only working copies. Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.[1]:7 Rather, communication is only necessary when pushing or pulling changes to or from other peers. Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing inherent protection against data loss.[1]:4

Integration[edit] Some of the more advanced revision-control tools offer many other facilities, allowing deeper integration with other tools and software-engineering processes. Plugins are often available for IDEs such as Oracle JDeveloper, IntelliJ IDEA, Eclipse and Visual Studio. Delphi, NetBeans IDE, Xcode and GNU Emacs (via vc.el) come with integrated version control support.

Common vocabulary[edit] Terminology can vary from system to system, but some terms in common usage include:[6] Baseline  An approved revision of a document or source file from which subsequent changes can be made. See baselines, labels and tags. Branch  A set of files under version control may be branched or forked at a point in time so that, from that time forward, two copies of those files may develop at different speeds or in different ways independently of each other. Change  A change (or diff, or delta) represents a specific modification to a document under version control. The granularity of the modification considered a change varies between version control systems. Change list  On many version control systems with atomic multi-change commits, a change list (or CL), change set, update, or patch identifies the set of changes made in a single commit. This can also represent a sequential view of the source code, allowing the examination of source "as of" any particular changelist ID. Checkout  To check out (or co) is to create a local working copy from the repository. A user may specify a specific revision or obtain the latest. The term 'checkout' can also be used as a noun to describe the working copy. Clone  Cloning means creating a repository containing the revisions from another repository. This is equivalent to pushing or pulling into an empty (newly initialized) repository. As a noun, two repositories can be said to be clones if they are kept synchronized, and contain the same revisions. Commit  To commit (check in, ci or, more rarely, install, submit or record) is to write or merge the changes made in the working copy back to the repository. The terms 'commit' and 'checkin' can also be used as nouns to describe the new revision that is created as a result of committing. Conflict  A conflict occurs when different parties make changes to the same document, and the system is unable to reconcile the changes. A user must resolve the conflict by combining the changes, or by selecting one change in favour of the other. Delta compression  Most revision control software uses delta compression, which retains only the differences between successive versions of files. This allows for more efficient storage of many different versions of files. Dynamic stream  A stream in which some or all file versions are mirrors of the parent stream's versions. Export  exporting is the act of obtaining the files from the repository. It is similar to checking out except that it creates a clean directory tree without the version-control metadata used in a working copy. This is often used prior to publishing the contents, for example. Fetch  See pull. Forward integration  The process of merging changes made in the main trunk into a development (feature or team) branch. Head Also sometimes called tip, this refers to the most recent commit, either to the trunk or to a branch. The trunk and each branch have their own head, though HEAD is sometimes loosely used to refer to the trunk.[7] Import  importing is the act of copying a local directory tree (that is not currently a working copy) into the repository for the first time. Initialize  to create a new, empty repository. Interleaved deltas  some revision control software uses Interleaved deltas, a method that allows to store the history of text based files in a more efficient way than by using Delta compression. Label  See tag. Mainline  Similar to trunk, but there can be a mainline for each branch. Merge  A merge or integration is an operation in which two sets of changes are applied to a file or set of files. Some sample scenarios are as follows: A user, working on a set of files, updates or syncs their working copy with changes made, and checked into the repository, by other users.[8] A user tries to check in files that have been updated by others since the files were checked out, and the revision control software automatically merges the files (typically, after prompting the user if it should proceed with the automatic merge, and in some cases only doing so if the merge can be clearly and reasonably resolved). A branch is created, the code in the files is independently edited, and the updated branch is later incorporated into a single, unified trunk. A set of files is branched, a problem that existed before the branching is fixed in one branch, and the fix is then merged into the other branch. (This type of selective merge is sometimes known as a cherry pick to distinguish it from the complete merge in the previous case.) Promote  The act of copying file content from a less controlled location into a more controlled location. For example, from a user's workspace into a repository, or from a stream to its parent.[9] Pull, push Copy revisions from one repository into another. Pull is initiated by the receiving repository, while push is initiated by the source. Fetch is sometimes used as a synonym for pull, or to mean a pull followed by an update. Repository  The repository is where files' current and historical data are stored, often on a server. Sometimes also called a depot. Resolve  The act of user intervention to address a conflict between different changes to the same document. Reverse integration  The process of merging different team branches into the main trunk of the versioning system. Revision  Also version: A version is any change in form. In SVK, a Revision is the state at a point in time of the entire tree in the repository. Share The act of making one file or folder available in multiple branches at the same time. When a shared file is changed in one branch, it is changed in other branches. Stream  A container for branched files that has a known relationship to other such containers. Streams form a hierarchy; each stream can inherit various properties (like versions, namespace, workflow rules, subscribers, etc.) from its parent stream. Tag  A tag or label refers to an important snapshot in time, consistent across many files. These files at that point may all be tagged with a user-friendly, meaningful name or revision number. See baselines, labels and tags. Trunk The unique line of development that is not a branch (sometimes also called Baseline, Mainline or Master) Update  An update (or sync, but sync can also mean a combined push and pull) merges changes made in the repository (by other people, for example) into the local working copy. Update is also the term used by some CM tools (CM+, PLS, SMS) for the change package concept (see changelist). Synonymous with checkout in revision control systems that require each repository to have exactly one working copy (common in distributed systems) Working copy The working copy is the local copy of files from a repository, at a specific time or revision. All work done to the files in a repository is initially done on a working copy, hence the name. Conceptually, it is a sandbox.

See also[edit] Change control Changelog Comparison of version control software Distributed version control List of version control software Software configuration management Software versioning Versioning file system

Notes[edit] ^ In this case, edit buffers are a secondary form of working copy, and not referred to as such. ^ In principle two revisions can have identical timestamp, and thus cannot be ordered on a line. This is generally the case for separate repositories, though is also possible for simultaneous changes to several branches in a single repository. In these cases, the revisions can be thought of as a set of separate lines, one per repository or branch (or branch within a repository). ^ The revision or repository "tree" should not be confused with the directory tree of files in a working copy. ^ Note that if a new branch is based on HEAD, then topologically HEAD is no longer a tip, since it has a child. ^ "Mainline" can also refer to the main path in a separate branch.

References[edit] ^ a b c O'Sullivan, Bryan (2009). Mercurial: the Definitive Guide. Sebastopol: O'Reilly Media, Inc. ISBN 9780596555474. Retrieved 4 September 2015.  ^ "Google Docs", See what’s changed in a file, Google . ^ "CollabNet Extends Investment in Resources and Accelerates Development of Subversion Enterprise Features". CollabNet. Archived from the original on February 21, 2013.  ^ For Engineering drawings, see Whiteprint#Document control, for some of the manual systems in place in the twentieth century, for example, the Engineering Procedures of Hughes Aircraft, each revision of which required approval by Lawrence A. Hyland; see also the approval procedures instituted by the U.S. government. ^ Wheeler, David. "Comments on Open Source Software / Free Software (OSS/FS) Software Configuration Management (SCM) Systems". Retrieved May 8, 2007.  ^ Wingerd, Laura (2005). Practical Perforce. O'Reilly. ISBN 0-596-10185-6.  ^ Gregory, Gary (February 3, 2011). "Trunk vs. HEAD in Version Control Systems". Java, Eclipse, and other tech tidbits. Retrieved 2012-12-16.  ^ Collins-Sussman, Fitzpatrick & Pilato 2004, 1.5: SVN tour cycle resolve: ‘The G stands for merGed, which means that the file had local changes to begin with, but the changes coming from the repository didn't overlap with the local changes.’ ^ Concepts Manual (Version 4.7 ed.). Accurev. July 2008. 

Bibliography[edit] Collins-Sussman, Ben; Fitzpatrick, BW; Pilato, CM (2004), Version Control with Subversion, O'Reilly, ISBN 0-596-00448-6 

External links[edit] "Visual Guide to Version Control", Better explained . Better SCM Initiative : Comparison at the Wayback Machine (archived April 11, 2013). A useful summary of different systems and their features. Sink, Eric, "Source Control", SCM (how‐to) . The basics of version control. v t e Version control software Years, where available, indicate the date of first stable release. Systems with names in italics are no longer maintained or have planned end-of-life dates. Local only Free/open-source RCS (1982) SCCS (1972) Proprietary PVCS (1985) QVCS (1991) Client–server Free/open-source CVS (1986, 1990 in C) CVSNT (1998) QVCS Enterprise (1998) Subversion (2000) Proprietary AccuRev SCM (2002) ClearCase (1992) CMVC (1994) Dimensions CM (1980s) DSEE (1984) Endevor (1980s) Integrity (2001) Panvalet (1970s) Perforce Helix (1995) SCLM (1980s?) Software Change Manager (1970s) StarTeam (1995) Surround SCM (2002) Synergy (1990) Team Concert (2008) Team Foundation Server (2005) Visual Studio Team Services (2014) Vault (2003) Visual SourceSafe (1994) Distributed Free/open-source ArX (2003) BitKeeper (2000) Codeville (2005) Darcs (2002) DCVS (2002) Fossil (2007) Git (2005) GNU arch (2001) GNU Bazaar (2005) Mercurial (2005) Monotone (2003) SVK (2003) Veracity (2010) Proprietary TeamWare (1990s?) Code Co-op (1997) Plastic SCM (2006) Team Foundation Server (2013) Visual Studio Team Services (2014) Concepts Branch Fork Changeset Commit Gated commit Interleaved deltas Delta compression Data comparison Merge Repository Tag Trunk Category Comparison List Retrieved from "" Categories: Version controlVersion control systemsTechnical communicationSoftware development processDistributed version control systemsHidden categories: Articles needing additional references from April 2011All articles needing additional referencesArticles to be expanded from December 2017All articles to be expandedArticles with empty sections from December 2017All articles with empty sectionsArticles using small message boxesAll articles with unsourced statementsArticles with unsourced statements from December 2017Articles with unsourced statements from November 2016Articles with unsourced statements from January 2010Webarchive template wayback links

Navigation menu Personal tools Not logged inTalkContributionsCreate accountLog in Namespaces ArticleTalk Variants Views ReadEditView history More Search Navigation Main pageContentsFeatured contentCurrent eventsRandom articleDonate to WikipediaWikipedia store Interaction HelpAbout WikipediaCommunity portalRecent changesContact page Tools What links hereRelated changesUpload fileSpecial pagesPermanent linkPage informationWikidata itemCite this page Print/export Create a bookDownload as PDFPrintable version In other projects Wikimedia CommonsWikibooks Languages AfrikaansالعربيةБеларускаяБългарскиCatalàČeštinaDanskDeutschEestiEspañolEsperantoفارسیFrançaisGalego한국어ՀայերենHrvatskiBahasa IndonesiaItalianoעבריתҚазақшаLatviešuLietuviųMagyarNederlands日本語NorskPolskiPortuguêsRomânăРусскийSlovenščinaSuomiSvenskaதமிழ்ไทยTürkçeУкраїнськаTiếng Việt中文 Edit links This page was last edited on 23 December 2017, at 16:10. Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. By using this site, you agree to the Terms of Use and Privacy Policy. Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization. Privacy policy About Wikipedia Disclaimers Contact Wikipedia Developers Cookie statement Mobile view (window.RLQ=window.RLQ||[]).push(function(){mw.config.set({"wgPageParseReport":{"limitreport":{"cputime":"0.324","walltime":"0.398","ppvisitednodes":{"value":1427,"limit":1000000},"ppgeneratednodes":{"value":0,"limit":1500000},"postexpandincludesize":{"value":58637,"limit":2097152},"templateargumentsize":{"value":1902,"limit":2097152},"expansiondepth":{"value":11,"limit":40},"expensivefunctioncount":{"value":7,"limit":500},"entityaccesscount":{"value":0,"limit":400},"timingprofile":["100.00% 320.243 1 -total"," 32.37% 103.678 2 Template:Reflist"," 16.84% 53.931 3 Template:Fix"," 15.90% 50.923 3 Template:Cite_book"," 14.63% 46.862 2 Template:Citation_needed"," 12.44% 39.846 1 Template:Refimprove"," 11.70% 37.468 2 Template:Ambox"," 10.38% 33.242 3 Template:Delink"," 9.89% 31.672 1 Template:Redirect"," 7.72% 24.720 4 Template:Navbox"]},"scribunto":{"limitreport-timeusage":{"value":"0.157","limit":"10.000"},"limitreport-memusage":{"value":4337562,"limit":52428800}},"cachereport":{"origin":"mw1219","timestamp":"20180115170905","ttl":1900800,"transientcontent":false}}});});(window.RLQ=window.RLQ||[]).push(function(){mw.config.set({"wgBackendResponseTime":85,"wgHostname":"mw1324"});});

Revision_control - Photos and All Basic Informations

Revision_control More Links

Revision Control SystemWikipedia:VerifiabilityHelp:Introduction To Referencing With Wiki Markup/1Help:Maintenance Template RemovalSoftware Configuration ManagementComputer ProgramTimestampWritingEdition (book)Specification (technical Standard)Software DevelopmentWord ProcessorSpreadsheetGroupwareContent Management SystemHelp:Page HistorySpammingList Of Version Control SoftwareSoftware EngineeringSource CodeSoftware DeveloperConfiguration FileComputer BugBranching (revision Control)Trunk (software)Configuration FilesComparison Of Version Control SoftwareGit (software)File LockingDistributed Revision ControlEnlargeGraph TheoryGraph TheoryLinear GraphDirected TreeMerge (revision Control)Directed Acyclic GraphWhiteprintWikipedia:Citation NeededProduct Data ManagementWikipedia:Citation NeededServer (computing)Atomic CommitConcurrent Versions SystemConcurrent AccessFile LockingMerge (revision Control)Merge (revision Control)Text FileImage FileLogicPlug-in (computing)Wikipedia:Citation NeededConfiguration ManagementBaseline (configuration Management)Distributed Version ControlClient-server ModelGood FaithPatch (Unix)Plug-in (computing)Integrated Development EnvironmentOracle JDeveloperIntelliJ IDEAEclipse (computing)Visual StudioDelphi (programming Language)NetBeansXcodeGNU EmacsBaseline (configuration Management)Branching (revision Control)DiffDelta EncodingAtomic TransactionCommit (revision Control)Delta CompressionInterleaved DeltasDelta CompressionMerge (revision Control)Repository (version Control)Software VersioningSVKRevision TagTrunk (software)Sandbox (software Development)Change ControlChangelogComparison Of Version Control SoftwareDistributed Version ControlList Of Version Control SoftwareSoftware Configuration ManagementSoftware VersioningVersioning File SystemInternational Standard Book NumberSpecial:BookSources/9780596555474Google DocsGoogleCollabNetWhiteprintHughes AircraftLawrence A. HylandInternational Standard Book NumberSpecial:BookSources/0-596-10185-6International Standard Book NumberSpecial:BookSources/0-596-00448-6Wayback MachineTemplate:Version Control SoftwareTemplate Talk:Version Control SoftwareFree And Open-source SoftwareRevision Control SystemSource Code Control SystemProprietary SoftwarePVCSQVCSConcurrent Versions SystemCVSNTQVCSApache SubversionAccuRev SCMRational ClearCaseIBM Configuration Management Version Control (CMVC)Dimensions CMApollo ComputerEndevorPTC IntegrityPanvaletPerforce HelixIBM Software Configuration And Library ManagerCA Harvest Software Change ManagerStarTeamSurround SCMRational SynergyRational Team ConcertTeam Foundation ServerMicrosoft Visual StudioVault (version Control System)Microsoft Visual SourceSafeDistributed Version ControlArXBitKeeperCodevilleDarcsDistributed Concurrent Versions SystemFossil (software)GitGNU ArchGNU BazaarMercurialMonotone (software)SVKVeracity (software)Sun WorkShop TeamWareCode Co-opPlastic SCMTeam Foundation ServerVisual Studio Team ServicesBranching (version Control)Fork (software Development)ChangesetCommit (version Control)Gated CommitInterleaved DeltasDelta EncodingData ComparisonMerge (version Control)Repository (version Control)Revision TagTrunk (software)Category:Version Control SystemsComparison Of Version Control SoftwareList Of Version Control SoftwareHelp:CategoryCategory:Version ControlCategory:Version Control SystemsCategory:Technical CommunicationCategory:Software Development ProcessCategory:Distributed Version Control SystemsCategory:Articles Needing Additional References From April 2011Category:All Articles Needing Additional ReferencesCategory:Articles To Be Expanded From December 2017Category:All Articles To Be ExpandedCategory:Articles With Empty Sections From December 2017Category:All Articles With Empty SectionsCategory:Articles Using Small Message BoxesCategory:All Articles With Unsourced StatementsCategory:Articles With Unsourced Statements From December 2017Category:Articles With Unsourced Statements From November 2016Category:Articles With Unsourced Statements From January 2010Category:Webarchive Template Wayback LinksDiscussion About Edits From This IP Address [n]A List Of Edits Made From This IP Address [y]View The Content Page [c]Discussion About The Content Page [t]Edit This Page [e]Visit The Main Page [z]Guides To Browsing WikipediaFeatured Content – The Best Of WikipediaFind Background Information On Current EventsLoad A Random Article [x]Guidance On How To Use And Edit WikipediaFind Out About WikipediaAbout The Project, What You Can Do, Where To Find ThingsA List Of Recent Changes In The Wiki [r]List Of All English Wikipedia Pages Containing Links To This Page [j]Recent Changes In Pages Linked From This Page [k]Upload Files [u]A List Of All Special Pages [q]Wikipedia:AboutWikipedia:General Disclaimer

view link view link view link view link view link