Editing Version control (section)

==Source-management models==
Traditional revision control systems use a centralized model where all the revision control functions take place on a shared [[Server (computing)|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===
{{Main|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; Concurrent Versions System lacks this feature.<ref>{{cite book |last1=Smart |first1=John Ferguson |title=Java Power Tools |date=2008 |publisher="O'Reilly Media, Inc." |isbn=978-1-4919-5454-6 |page=301 |url=https://books.google.com/books?id=YoTvBpKEx5EC&q=cvs+doesn%27t+support+atomic+commit&pg=PA301 |access-date=20 July 2019 |language=en |archive-date=26 September 2024 |archive-url=https://web.archive.org/web/20240926164948/https://books.google.com/books?id=YoTvBpKEx5EC&q=cvs+doesn%27t+support+atomic+commit&pg=PA301#v=snippet&q=cvs%20doesn't%20support%20atomic%20commit&f=false |url-status=live }}</ref>

===File locking===
The simplest method of preventing "[[concurrent access]]" problems involves [[file locking|locking files]] so that only one developer at a time has write access to the central "[[Repository (version control)|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). 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, forcing a difficult manual merge when the other changes are finally checked in. In a large organization, files can be left "checked out" and locked and forgotten about as developers move between projects - these tools may or may not make it easy to see who has a file checked out.

===Version merging===
{{Main|Merge (version 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 (revision control)|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 file]]s. The result of a merge of two [[image file]]s 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 [[Plug-in (computing)|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===
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|date=January 2010}}; 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 (configuration management)|''baseline'']].