This chapter describes Emacs features for maintaining large
programs. If you are maintaining a large Lisp program, then in
addition to the features described here, you may find
-the @file{ERT} (``Emacs Lisp Regression Testing'') library useful
+the Emacs Lisp Regression Testing (ERT) library useful
(@pxref{Top,,ERT,ert, Emacs Lisp Regression Testing}).
@menu
@cindex src
@item
SRC (src) is RCS, reloaded - a specialized version-control system
-designed for single-file projects worked on by only one person. It
+designed for single-file projects worked on by only one person. It
allows multiple files with independent version-control histories to
exist in one directory, and is thus particularly well suited for
maintaining small documents, scripts, and dotfiles. While it uses RCS
to the master repository.
On a graphical display, you can move the mouse over this mode line
-indicator to pop up a ``tool-tip'', which displays a more verbose
+indicator to pop up a tool-tip, which displays a more verbose
description of the version control status. Pressing @kbd{Mouse-1}
over the indicator pops up a menu of VC commands, identical to
@samp{Tools / Version Control} on the menu bar.
@findex vc-next-action
@kindex C-x v v
The principal VC command is a multi-purpose command, @kbd{C-x v v}
-(@code{vc-next-action}), which performs the ``most appropriate''
+(@code{vc-next-action}), which performs the most appropriate
action on the current VC fileset: either registering it with a version
control system, or committing it, or unlocking it, or merging changes
into it. The precise actions are described in detail in the following
subsections. You can use @kbd{C-x v v} either in a file-visiting
buffer or in a VC Directory buffer.
- Note that VC filesets are distinct from the ``named filesets'' used
+ Note that VC filesets are distinct from the named filesets used
for viewing and visiting files in functional groups
(@pxref{Filesets}). Unlike named filesets, VC filesets are not named
and don't persist across sessions.
@item
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; @pxref{Registering}.)
+however, that a fileset is allowed to include both newly-added
+files and modified files; @pxref{Registering}.)
@item
If none of the files in the VC fileset are registered with a version
If committing to a shared repository, the commit may fail if the
repository that 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 @kbd{C-x v +} (@pxref{VC
-Pull}) or @kbd{C-x v m} (@pxref{Merging}). On a centralized version
-control system, type @kbd{C-x v v} again to merge in the repository
-changes.
+decentralized version control system, use @kbd{C-x v +}
+(@pxref{Pulling / Pushing}) or @kbd{C-x v m} (@pxref{Merging}).
+On a centralized version control system, type @kbd{C-x v v} again to
+merge in the repository changes.
@item
Finally, if you are using a centralized version control system, check
been changed in the repository, offer to update it.
@end itemize
- These rules also apply when you use RCS in its ``non-locking'' mode,
+ 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, his
@item
If each file is locked by another user, ask whether you want to
-``steal the lock''. If you say yes, the file becomes locked by you,
+steal the lock. If you say yes, the file becomes locked by you,
and a warning message is sent to the user who had formerly locked the
file.
@end itemize
revision into the working tree. You can also specify a revision on
another branch by giving its revision or branch ID (@pxref{Switching
Branches}). An empty argument (i.e., @kbd{C-u C-x v v @key{RET}})
-checks out the latest (``head'') revision on the current branch.
+checks out the latest (head) revision on the current branch.
This signals an error on a decentralized version control system.
Those systems do not let you specify your own revision IDs, nor do
-they use the concept of ``checking out'' individual files.
+they use the concept of checking out individual files.
@end itemize
@node Log Buffer
@findex log-edit-show-files
@kindex C-c C-d @r{(Log Edit mode)}
@findex log-edit-show-diff
- While in the @file{*vc-log*} buffer, the ``current VC fileset'' is
+ While in the @file{*vc-log*} buffer, the current VC fileset is
considered to be the fileset that will be committed if you type
@w{@kbd{C-c C-c}}. To view a list of the files in the VC fileset,
type @w{@kbd{C-c C-f}} (@code{log-edit-show-files}). To view a diff
registers the file into that repository.
On most version control systems, registering a file with @kbd{C-x v
-i} or @kbd{C-x v v} adds it to the ``working tree'' but not to the
+i} or @kbd{C-x v v} adds it to the working tree but not to the
repository. Such files are labeled as @samp{added} in the VC
Directory buffer, and show a revision ID of @samp{@@@@} in the mode
line. To make the registration take effect in the repository, you
@kindex C-x v g
Many version control systems allow you to view files @dfn{annotated}
with per-line revision information, by typing @kbd{C-x v g}
-(@code{vc-annotate}). This creates a new buffer (the ``annotate
-buffer'') displaying the file's text, with each line colored to show
+(@code{vc-annotate}). This creates a new annotate buffer
+displaying the file's text, with each line colored to show
how old it is. Red text is new, blue is old, and intermediate colors
indicate intermediate ages. By default, the color is scaled over the
full range of ages, such that the oldest changes are blue, and the
On a decentralized version control system, the @kbd{C-x v I}
(@code{vc-log-incoming}) command displays a log buffer showing the
changes that will be applied, the next time you run the version
-control system's ``pull'' command to get new revisions from another
-repository (@pxref{VC Pull}). This other repository is the default
+control system's pull command to get new revisions from another
+repository (@pxref{Pulling / Pushing}). This other repository is the default
one from which changes are pulled, as defined by the version control
system; with a prefix argument, @code{vc-log-incoming} prompts for a
specific repository. Similarly, @kbd{C-x v O}
(@code{vc-log-outgoing}) shows the changes that will be sent to
-another repository, the next time you run the ``push'' command; with a
+another repository, the next time you run the push command; with a
prefix argument, it prompts for a specific destination repository.
In the @file{*vc-change-log*} buffer, you can use the following keys
The VC Directory buffer contains a list of version-controlled files
and their version control statuses. It lists files in the current
directory (the one specified when you called @kbd{C-x v d}) and its
-subdirectories, but only those with a ``noteworthy'' status. Files
+subdirectories, but only those with a noteworthy status. Files
that are up-to-date (i.e., the same as in the repository) are
omitted. If all the files in a subdirectory are up-to-date, the
subdirectory is not listed either. As an exception, if a file has
@subsubsection VC Directory Commands
Emacs provides several commands for navigating the VC Directory
-buffer, and for ``marking'' files as belonging to the current VC
+buffer, and for marking files as belonging to the current VC
fileset.
@table @kbd
One use of version control is to support multiple independent lines
of development, which are called @dfn{branches}. Amongst other
-things, branches can be used for maintaining separate ``stable'' and
-``development'' versions of a program, and for developing unrelated
+things, branches can be used for maintaining separate stable and
+development versions of a program, and for developing unrelated
features in isolation from one another.
VC's support for branch operations is currently fairly limited. For
@menu
* Switching Branches:: How to get to another existing branch.
-* VC Pull:: Updating the contents of a branch.
+* Pulling / Pushing:: Receiving/sending changes from/to elsewhere.
* Merging:: Transferring changes between branches.
* Creating Branches:: How to start a new branch.
@end menu
branch until you switch away; for instance, any VC filesets that you
commit will be committed to that specific branch.
-@node VC Pull
-@subsubsection Pulling Changes into a Branch
+@node Pulling / Pushing
+@subsubsection Pulling/Pushing Changes into/from a Branch
@table @kbd
@item C-x v +
On a decentralized version control system, update the current branch
-by ``pulling in'' changes from another location.
+by pulling in changes from another location.
On a centralized version control system, update the current VC
fileset.
+
+@item C-x v P
+On a decentralized version control system, push changes from the
+current branch to another location. This concept does not exist
+for centralized version control systems.
@end table
@kindex C-x v +
On a centralized version control system like CVS, @kbd{C-x v +}
updates the current VC fileset from the repository.
+@kindex C-x v P
+@findex vc-push
+ On a decentralized version control system, the command @kbd{C-x v P}
+(@code{vc-push}) sends changes from your current branch to another location.
+With a prefix argument, the command prompts for the exact
+version control command to use, which lets you specify where to push
+changes. Otherwise, it pushes to a default location determined
+by the version control system.
+
+ Prior to pushing, you can use @kbd{C-x v O} (@code{vc-log-outgoing})
+to view a log buffer of the changes to be sent. @xref{VC Change Log}.
+
+This command is currently supported only by Bazaar, Git, and Mercurial.
+It signals an error for centralized version control systems.
+
@node Merging
@subsubsection Merging Branches
@cindex merging changes
@smallexample
1993-05-25 Richard Stallman <rms@@gnu.org>
- * man.el: Rename symbols `man-*' to `Man-*'.
+ * man.el: Rename symbols 'man-*' to 'Man-*'.
(manual-entry): Make prompt string clearer.
* simple.el (blink-matching-paren-distance):
A project may contain one or more @dfn{targets}. A target can be an
object file, executable program, or some other type of file, which is
-``built'' from one or more of the files in the project.
+built from one or more of the files in the project.
To add a new @dfn{target} to a project, type @kbd{C-c . t}
(@code{M-x ede-new-target}). This command also asks if you wish to
-``add'' the current file to that target, which means that the target
+add the current file to that target, which means that the target
is to be built from that file. After you have defined a target, you
can add more files to it by typing @kbd{C-c . a}
(@code{ede-add-file}).