<html><head><meta name="color-scheme" content="light dark"></head><body><pre style="word-wrap: break-word; white-space: pre-wrap;">\documentclass[onecolumn,letterpaper,11pt]{article}

%===================================================================
\input{common_latex/common_latex_packages}
\input{common_latex/common_latex_definitions}
\input{common_latex/common_latex_help_format}
%===================================================================

\begin{document}

\begin{labcover}
\labtitle{Help Topic: The SVN Update Command}
\vspace{0.1in}
\labdate{Spring 2021}
\vspace{0.1in}
\labauth{Michael Benjamin, mikerb@mit.edu}
\labauth{Department of Mechanical Engineering}
\labauth{MIT, Cambridge MA 02139}
\labline
\end{labcover}

\wikidoc{file=Help.SVNUpdate}
\wikidoc{auth=mikerb@mit.edu}

%====================================================================
\section*{The SVN \cmd{update} Command}
%====================================================================

The \cmd{svn update} command lets you refresh your locally checked out
repository with any changes in the repository HEAD on the server. It
also tells you {\em what} has been changed, added, deleted. If a
change has been made to a file you have also changed locally, svn will
try to merge those changes. If unsuccessful, it will report a
conflict. More on this is discussed below.  More info can always be
found by Googling "Subversion book" and reading the full PDF online
free, or just typing \cmd{svn help update} anytime on the command
line.

%---------------------------------------------------------------------
\subsection*{Basic usage of the update \cmd{update} command}

The basic syntax for the \cmd{svn update} command is:

\vspace{0.05in}
\begin{consoleverb}
 $ svn update        (invoked somewhere within previously checked out tree)
\end{consoleverb}
\vspace{0.15in}

\noindent
The \cmd{svn update} command requires a network connection to the
server and perhaps a password if it is not an anonymous read-only
repository.  The command may be invoked anywhere in the locally
checked out tree. {\em If it is invoked in a subtree, updates only for
that subtree are pulled from the server.} The update will work
recursively for all directories within the directory it is
invoked. This latter behavior is usually what you want, but can be
overridden with the \cmd{--depth} argument, not covered here, but
covered in the online Subversion book.

%---------------------------------------------------------------------
\subsection*{Deciphering the output of the svn \cmd{update} command}

In the simplest case, when your locally checked out tree is up to date
with the server, you will see a two-line response like the following:

\vspace{0.1in}
\begin{consoleverb}
 $ svn update
 Updating '.':
 At revision 2675.
\end{consoleverb}
\vspace{0.1in}

\noindent
The revision number output is convenient since you and co-developers can 
easily confirm that you're working with the same version from the server
after you both do an update. 

\pskip
Beware of the common "gotcha". Two developers both perform an update
and confirm that they have the same revision - but their code is
acting differently. This can drive people bonkers. The thing to
remember is that, even though you both have the same revision, one or
both of you may have local modifications that you have not yet checked
into the server. Very likely one of these local modifications is
causing the difference in observed behavior. Check for local
modifications using the \cmd{svn status} command, discussed in a
separate help topic or in the svn book.

\pskip
\noindent
Here's an example output after an update:

\vspace{0.1in}
\begin{consoleverb}
 $ svn update
 Updating '.':
 U    Figure.h
 A    Object.h
 G    Items.cpp
 A    Object.cpp
\end{consoleverb}
\vspace{0.15in}

\noindent
This indicates that:

\begin{packed_itemize}[1]
\item The file \var{Figure.h} was updated with changes pulled in from the 
server. There were {\em no} local modifications to this file prior to the update.
\item The files \var{Object.h} and \var{Object.cpp} are newly added from 
the server to your local checkout.
\item The file \var{Items.cpp} had changes known to the server and separate changes
in the local copy of the file successfully merged. (Note the
server will not have the local changes until you commit the changes to
the server.)
\end{packed_itemize}

\vspace{0.1in}
\noindent
The primary cases you will likely see the most frequently are below. (See 
\cmd{svn help update} for a more complete list.)

\vspace{0.1in}
\begin{fileverb}
 A  Added
 D  Deleted
 U  Updated
 C  Conflict
 G  Merged
\end{fileverb}
\vspace{0.15in}

\noindent
The topic of a conflict (C) is discussed next.


%---------------------------------------------------------------------
\subsection*{Dealing with a conflict after an svn \cmd{update}}

Subversion is pretty good at merging two files with separate
changes. It usually gets things right, and in my experience errs on
the side of being conservative. It has never merged two files that
didn't deserve merging.  But sometimes flags as a conflict an issue
that is easily resolved when it hits human eyes. In the case above, if
the file \var{Items.cpp} was {\em not} able to be merged by the svn
algorithms, you would have see this instead:

\vspace{0.1in}
\begin{consoleverb}
 $ svn update
 Updating '.':
 U    XWFigure.h
 A    XKObject.h
 C    XWItems.cpp
 A    XKObject.cpp
 Updated to revision 303.
 Conflict discovered in file 'Items.cpp'.
 Select: (p) postpone, (df) show diff, (e) edit file, (m) merge,
         (mc) my side of conflict, (tc) their side of conflict,
         (s) show all options: 
\end{consoleverb}
\vspace{0.15in}

\noindent
The choices are a fairly self-explanatory. I choose (e) most of the time
unless I just happen to know that my local change is worth discarding, 
in which case I choose (tc). The (m) option puts you into an interactive
tool that helps you de-conflict. The (df) option just shows you the 
difference between two files. The (p) option just kicks the can down the 
road and leaves the file marked as conflicted. You won't be able to check
in local changes until that conflict is resolved. 

\pskip

The one worth special mention is the (e) option. It's probably best to
deal with any conflicts as they come up, and dealing with them during
the update process is my own general practice. Selecting the (e)
option launches an editor in your terminal window. The editor will show
a file with the conflicts delimited as by example below. 

\vspace{0.1in}
\begin{consoleverb}
 &lt;&lt;&lt;&lt;&lt;&lt;&lt; .mine
 // string fruit = "apples";
 =======
 // string fruit = "pears";
 &gt;&gt;&gt;&gt;&gt;&gt;&gt; .r305
\end{consoleverb}
\vspace{0.15in}

\noindent
You can resolve the conflict by picking one version of a block of code
and deleting the other (and the delimiter lines), and saving the file.
Once you have quit the editor, you are prompted with the same set of 
options with one additional option, the (r) option:

\vspace{0.1in}
\begin{consoleverb}
 Select: (p) postpone, (df) show diff, (e) edit file, (m) merge,
         (r) mark resolved, (mc) my side of conflict,
         (tc) their side of conflict, (s) show all options: 
\end{consoleverb}
\vspace{0.15in}

\noindent
By choosing the (r) option you are acknowledging to svn that all is
good from your perspective, for that file. It will then continue with
the rest of the update. 

%------------------------------------------------------------------
\subsection*{Configuring SVN with an editor of your choosing}

Getting back to that issue of launching an editor to resolve conflicts
as described above. "Which editor?" you may ask. The editor chosen is
determined by how you have certain environment variables set in your
shell configuration. It will first look for the value of
the \var{SVN\_EDITOR} variable, and fall back to the value for
the \var{EDITOR} environment variable. If these are not set, svn may
not allow you to select the (e) option. 

\pskip
\noindent
If you're a \var{tcsh} user, add the following lines to
your \var{.cshrc} file, with the editor of your choosing:

\vspace{0.1in}
\begin{fileverb}
  setenv EDITOR 'emacs'
  setenv SVN_EDITOR 'emacs'
\end{fileverb}
\vspace{0.15in}

\noindent
If you're a \var{bash} user, add the following lines to
your \var{.bashrc} file, with the editor of your choosing:

\vspace{0.1in}
\begin{fileverb}
  export EDITOR=emacs
  ecport SVN_EDITOR=emacs
\end{fileverb}
\vspace{0.15in}

\noindent
To check the prevailing value of an environment variable, e.g., \var{EDITOR}, 
just type this on the command line: \cmd{echo \$EDITOR}.

\pskip

\noindent
(The \var{EDITOR} is also relevant when checking in (committing) code and 
adding a commit comment.)

\end{document}

</pre></body></html>