GNU Emacs
Dashboard Basic Version Control with Merging

On a merging-based version control system (i.e., most modern ones; see Merge-based vs Lock-based Version Control), C-x v v does the following:

  • If there is more than one file in the VC fileset and the files have inconsistent version control statuses, signal an error. (Note, however, that a fileset is allowed to include both newly-added files and modified files; see Registering a File for Version Control.)

  • If none of the files in the VC fileset are registered with a version control system, register the VC fileset, i.e., place it under version control. See Registering a File for Version Control. If Emacs cannot find a system to register under, it prompts for a repository type, creates a new repository, and registers the VC fileset with it.

  • If every work file in the VC fileset is unchanged, do nothing.

  • If every work file in the VC fileset has been modified, commit the changes. To do this, Emacs pops up a *vc-log* buffer; type the desired log entry for the new revision, followed by C-c C-c to commit. See Features of the Log Entry Buffer.

If committing to a shared repository, the commit may fail if the repository has been changed since your last update. In that case, you must perform an update before trying again. On a decentralized version control system, use C-x v + (see Pulling/Pushing Changes into/from a Branch) or C-x v m (see Merging Branches). On a centralized version control system, type C-x v v again to merge in the repository changes.

  • Finally, if you are using a centralized version control system, check if each work file in the VC fileset is up-to-date. If any file has been changed in the repository, offer to update it.

These rules also apply when you use RCS in its non-locking mode, except that changes are not automatically merged from the repository. Nothing informs you if another user has committed changes in the same file since you began editing it; when you commit your revision, that other user’s changes are removed (however, they remain in the repository and are thus not irrevocably lost). Therefore, you must verify that the current revision is unchanged before committing your changes. In addition, locking is possible with RCS even in this mode: C-x v v with an unmodified file locks the file, just as it does with RCS in its normal locking mode (see Basic Version Control with Locking).