<?xml version="1.0" encoding="utf-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Version Control Basics</title>
<link rel="stylesheet" type="text/css" href="styles.css" />
<meta name="generator" content="DocBook XSL Stylesheets V1.79.1" />
<style type="text/css">
body { background-image: url('images/draft.png');
background-repeat: no-repeat;
background-position: top left;
/* The following properties make the watermark "fixed" on the page. */
/* I think that's just a bit too distracting for the reader... */
/* background-attachment: fixed; */
/* background-position: center center; */
}</style>
<link rel="home" href="index.html" title="Version Control with Subversion [DRAFT]" />
<link rel="up" href="svn.basic.html" title="Chapter 1. Fundamental Concepts" />
<link rel="prev" href="svn.basic.html" title="Chapter 1. Fundamental Concepts" />
<link rel="next" href="svn.basic.in-action.html" title="Version Control the Subversion Way" />
</head>
<body>
<div xmlns="" id="vcws-version-notice">
<p>This text is a work in progress—highly subject to
change—and may not accurately describe any released
version of the Apache™ Subversion® software.
Bookmarking or otherwise referring others to this page is
probably not such a smart idea. Please visit
<a href="http://www.svnbook.com/">http://www.svnbook.com/</a>
for stable versions of this book.</p>
</div>
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr>
<th colspan="3" align="center">Version Control Basics</th>
</tr>
<tr>
<td width="20%" align="left"><a accesskey="p" href="svn.basic.html">Prev</a> </td>
<th width="60%" align="center">Chapter 1. Fundamental Concepts</th>
<td width="20%" align="right"> <a accesskey="n" href="svn.basic.in-action.html">Next</a></td>
</tr>
</table>
<hr />
</div>
<div class="sect1">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a id="svn.basic.version-control-basics"></a>Version Control Basics</h2>
</div>
</div>
</div>
<p>
<a id="idm447" class="indexterm"></a>A version control system (or revision control
system) is a system that tracks incremental versions (or
revisions) of files and, in some cases, directories over time.
Of course, merely tracking the various versions of a user's (or
group of users') files and directories isn't very interesting in
itself. What makes a version control system useful is the fact
that it allows you to explore the changes which resulted in each
of those versions and facilitates the arbitrary recall of the
same.</p>
<p>In this section, we'll introduce some fairly high-level
version control system components and concepts. We'll limit our
discussion to modern version control systems—in today's
interconnected world, there is very little point in
acknowledging version control systems which cannot
operate across wide-area networks.</p>
<div class="sect2">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="svn.basic.repository"></a>The Repository</h3>
</div>
</div>
</div>
<p>
<a id="idm453" class="indexterm"></a>
<a id="idm455" class="indexterm"></a>
<a id="idm458" class="indexterm"></a>At the core of the version control system is a
repository, which is the central store of that system's data.
The repository usually stores information in the form of a
<em class="firstterm">filesystem tree</em>—a hierarchy of
files and directories. Any number of
<em class="firstterm">clients</em> connect to the repository, and
then read or write to these files. By writing data, a client
makes the information available to others; by reading data,
the client receives information from others.
<a class="xref" href="svn.basic.version-control-basics.html#svn.basic.repository.dia-1" title="Figure 1.1. A typical client/server system">Figure 1.1, “A typical client/server system”</a> illustrates
this.</p>
<div class="figure">
<a id="svn.basic.repository.dia-1"></a>
<p class="title">
<strong>Figure 1.1. A typical client/server system</strong>
</p>
<div class="figure-contents">
<div>
<img src="images/ch02dia1.png" alt="A typical client/server system" />
</div>
</div>
</div>
<br class="figure-break" />
<p>Why is this interesting? So far, this sounds like the
definition of a typical file server. And indeed, the
repository <span class="emphasis"><em>is</em></span> a kind of file server, but
it's not your usual breed. What makes the repository special
is that as the files in the repository are changed, the
repository remembers each version of those files.</p>
<p>When a client reads data from the repository, it normally
sees only the latest version of the filesystem tree. But what
makes a version control client interesting is that it also has
the ability to request previous states of the filesystem from
the repository. A version control client can ask historical
questions such as <span class="quote">“<span class="quote">What did this directory contain last
Wednesday?</span>”</span> and <span class="quote">“<span class="quote">Who was the last person to
change this file, and what changes did he make?</span>”</span>
These are the sorts of questions that are at the heart of any
version control system.</p>
</div>
<div class="sect2">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="svn.basic.working-copy"></a>The Working Copy</h3>
</div>
</div>
</div>
<p>
<a id="idm475" class="indexterm"></a>A version control system's value comes from the
fact that it tracks versions of files and directories, but the
rest of the software universe doesn't operate
on <span class="quote">“<span class="quote">versions of files and directories</span>”</span>. Most
software programs understand how to operate only on
a <span class="emphasis"><em>single</em></span> version of a specific type of
file. So how does a version control user interact with an
abstract—and, often, remote—repository full of
multiple versions of various files in a concrete fashion? How
does his or her word processing software, presentation
software, source code editor, web design software, or some
other program—all of which trade in the currency of
simple data files—get access to such files? The answer
is found in the version control construct known as
a <em class="firstterm">working copy</em>.</p>
<p>A working copy is, quite literally, a local copy of a
particular version of a user's VCS-managed data upon which
that user is free to work. Working copies<a href="#ftn.idm481" class="footnote" id="idm481"><sup class="footnote">[5]</sup></a> appear to other software
just as any other local directory full of files, so those
programs don't have to be <span class="quote">“<span class="quote">version-control-aware</span>”</span>
in order to read from and write to that data. The task of
managing the working copy and communicating changes made to
its contents to and from the repository falls squarely to the
version control system's client software.</p>
</div>
<div class="sect2">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="svn.basic.vsn-models"></a>Versioning Models</h3>
</div>
</div>
</div>
<p>If the primary mission of a version control system is to
track the various versions of digital information over time, a
very close secondary mission in any modern version control
system is to enable collaborative editing and sharing of that
data. But different systems use different strategies to
achieve this. It's important to understand these different
strategies, for a couple of reasons. First, it will help you
compare and contrast existing version control systems, in case
you encounter other systems similar to Subversion. Beyond
that, it will also help you make more effective use of
Subversion, since Subversion itself supports a couple of
different ways of working.</p>
<div class="sect3">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a id="svn.basic.vsn-models.problem-sharing"></a>The problem of file sharing</h4>
</div>
</div>
</div>
<p>All version control systems have to solve the same
fundamental problem: how will the system allow users to
share information, but prevent them from accidentally
stepping on each other's feet? It's all too easy for users
to accidentally overwrite each other's changes in the
repository.</p>
<p>Consider the scenario shown in
<a class="xref" href="svn.basic.version-control-basics.html#svn.basic.vsn-models.problem-sharing.dia-1" title="Figure 1.2. The problem to avoid">Figure 1.2, “The problem to avoid”</a>.
Suppose we have two coworkers, Harry and Sally. They each
decide to edit the same repository file at the same time.
If Harry saves his changes to the repository first, it's
possible that (a few moments later) Sally could accidentally
overwrite them with her own new version of the file. While
Harry's version of the file won't be lost forever (because
the system remembers every change), any changes Harry made
<span class="emphasis"><em>won't</em></span> be present in Sally's newer version
of the file, because she never saw Harry's changes to begin
with. Harry's work is still effectively lost—or at
least missing from the latest version of the file—and
probably by accident. This is definitely a situation we want
to avoid!</p>
<div class="figure">
<a id="svn.basic.vsn-models.problem-sharing.dia-1"></a>
<p class="title">
<strong>Figure 1.2. The problem to avoid</strong>
</p>
<div class="figure-contents">
<div>
<img src="images/ch02dia2.png" alt="The problem to avoid" />
</div>
</div>
</div>
<br class="figure-break" />
</div>
<div class="sect3">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a id="svn.basic.vsn-models.lock-unlock"></a>The lock-modify-unlock solution</h4>
</div>
</div>
</div>
<p>
<a id="idm500" class="indexterm"></a>Many version control systems use a
<em class="firstterm">lock-modify-unlock</em> model to address
the problem of many authors clobbering each other's work.
In this model, the repository allows only one person to
change a file at a time. This exclusivity policy is managed
using locks. Harry must <span class="quote">“<span class="quote">lock</span>”</span> a file before
he can begin making changes to it. If Harry has locked a
file, Sally cannot also lock it, and therefore cannot make
any changes to that file. All she can do is
wait for Harry to finish his changes, save the file and
release his lock. After Harry unlocks the file, Sally
can take her turn by locking the file. Then she may read
the latest version of the file and edit it.
<a class="xref" href="svn.basic.version-control-basics.html#svn.basic.vsn-models.lock-unlock.dia-1" title="Figure 1.3. The lock-modify-unlock solution">Figure 1.3, “The lock-modify-unlock solution”</a>
demonstrates this simple solution.</p>
<div class="figure">
<a id="svn.basic.vsn-models.lock-unlock.dia-1"></a>
<p class="title">
<strong>Figure 1.3. The lock-modify-unlock solution</strong>
</p>
<div class="figure-contents">
<div>
<img src="images/ch02dia3.png" alt="The lock-modify-unlock solution" />
</div>
</div>
</div>
<br class="figure-break" />
<p>The problem with the lock-modify-unlock model is that it's
a bit restrictive and often becomes a roadblock for
users:</p>
<div class="itemizedlist">
<ul class="itemizedlist" style="list-style-type: disc; ">
<li class="listitem">
<p><span class="emphasis"><em>Locking may cause administrative
problems.</em></span>
Sometimes Harry will lock a file and then forget about it.
Meanwhile, because Sally is still waiting to edit the file,
her hands are tied. And then Harry goes on vacation. Now
Sally has to get an administrator to release Harry's lock.
The situation ends up causing a lot of unnecessary delay
and wasted time.</p>
</li>
<li class="listitem">
<p><span class="emphasis"><em>Locking may cause unnecessary
serialization.</em></span>
What if Harry is editing the beginning of a text file,
and Sally simply wants to edit the end of the same file?
These changes don't overlap at all. They could easily
edit the file simultaneously, and no great harm would
come, assuming the changes were properly merged together.
There's no need for them to take turns in this
situation.</p>
</li>
<li class="listitem">
<p><span class="emphasis"><em>Locking may create a false sense of
security.</em></span>
Suppose Harry locks and edits file A, while Sally
simultaneously locks and edits file B. But what if A and
B depend on one another, and the changes made to each are
semantically incompatible? Suddenly A and B don't work
together anymore. The locking system was powerless to
prevent the problem—yet it somehow provided a false
sense of security. It's easy for Harry and Sally to
imagine that by locking files, each is beginning a safe,
insulated task, and thus they need not bother discussing
their incompatible changes early on. Locking often
becomes a substitute for real communication.</p>
</li>
</ul>
</div>
</div>
<div class="sect3">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a id="svn.basic.vsn-models.copy-merge"></a>The copy-modify-merge solution</h4>
</div>
</div>
</div>
<p>
<a id="idm524" class="indexterm"></a>Subversion, CVS, and many other version control
systems use a <em class="firstterm">copy-modify-merge</em> model
as an alternative to locking. In this model, each user's
client contacts the project repository and creates a
personal working copy. Users then work simultaneously and
independently, modifying their private copies. Finally, the
private copies are merged together into a new, final
version. The version control system often assists with the
merging, but ultimately, a human being is responsible for
making it happen correctly.</p>
<p>
<a id="idm530" class="indexterm"></a>Here's an example. Say that Harry and Sally
each create working copies of the same project, copied from
the repository. They work concurrently and make changes to
the same file A within their copies. Sally saves her
changes to the repository first. When Harry attempts to
save his changes later, the repository informs him that his
file A is <em class="firstterm">out of date</em>. In other
words, file A in the repository has somehow changed since he
last copied it. So Harry asks his client to merge any new
changes from the repository into his working copy of file A.
Chances are that Sally's changes don't overlap with his own;
once he has both sets of changes integrated, he saves his
working copy back to the repository.
<a class="xref" href="svn.basic.version-control-basics.html#svn.basic.vsn-models.copy-merge.dia-1" title="Figure 1.4. The copy-modify-merge solution">Figure 1.4, “The copy-modify-merge solution”</a> and
<a class="xref" href="svn.basic.version-control-basics.html#svn.basic.vsn-models.copy-merge.dia-2" title="Figure 1.5. The copy-modify-merge solution (continued)">Figure 1.5, “The copy-modify-merge solution (continued)”</a> show
this process.</p>
<div class="figure">
<a id="svn.basic.vsn-models.copy-merge.dia-1"></a>
<p class="title">
<strong>Figure 1.4. The copy-modify-merge solution</strong>
</p>
<div class="figure-contents">
<div>
<img src="images/ch02dia4.png" alt="The copy-modify-merge solution" />
</div>
</div>
</div>
<br class="figure-break" />
<div class="figure">
<a id="svn.basic.vsn-models.copy-merge.dia-2"></a>
<p class="title">
<strong>Figure 1.5. The copy-modify-merge solution (continued)</strong>
</p>
<div class="figure-contents">
<div>
<img src="images/ch02dia5.png" alt="The copy-modify-merge solution (continued)" />
</div>
</div>
</div>
<br class="figure-break" />
<p>
<a id="idm542" class="indexterm"></a>But what if Sally's changes
<span class="emphasis"><em>do</em></span> overlap with Harry's changes? What
then? This situation is called a
<em class="firstterm">conflict</em>, and it's usually not much
of a problem. When Harry asks his client to merge the
latest repository changes into his working copy, his copy of
file A is somehow flagged as being in a state of conflict:
he'll be able to see both sets of conflicting changes and
manually choose between them. Note that software can't
automatically resolve conflicts; only humans are capable of
understanding and making the necessary intelligent choices.
Once Harry has manually resolved the overlapping
changes—perhaps after a discussion with Sally—he
can safely save the merged file back to the
repository.</p>
<p>The copy-modify-merge model may sound a bit chaotic, but
in practice, it runs extremely smoothly. Users can work in
parallel, never waiting for one another. When they work on
the same files, it turns out that most of their concurrent
changes don't overlap at all; conflicts are infrequent. And
the amount of time it takes to resolve conflicts is usually
far less than the time lost by a locking system.</p>
<p>In the end, it all comes down to one critical factor:
user communication. When users communicate poorly, both
syntactic and semantic conflicts increase. No system can
force users to communicate perfectly, and no system can
detect semantic conflicts. So there's no point in being
lulled into a false sense of security that a locking system
will somehow prevent conflicts; in practice, locking seems
to inhibit productivity more than anything else.</p>
<div class="sidebar">
<a id="svn.basic.vsn-models.copy-merge.sb-1"></a>
<div class="titlepage">
<div>
<div>
<p class="title">
<strong>When Locking Is Necessary</strong>
</p>
</div>
</div>
</div>
<p>While the lock-modify-unlock model is considered
generally harmful to collaboration, sometimes
locking is appropriate.</p>
<p>The copy-modify-merge model is based on the assumption
that files are contextually mergeable—that is, that the
majority of the files in the repository are line-based text
files (such as program source code). But for files with
binary formats, such as artwork or sound, it's often
impossible to merge conflicting changes. In these
situations, it really is necessary for users to take strict
turns when changing the file. Without serialized access,
somebody ends up wasting time on changes that are ultimately
discarded.</p>
<p>While Subversion is primarily a copy-modify-merge
system, it still recognizes the need to lock an occasional
file, and thus provides mechanisms for this. We discuss
this feature in <a class="xref" href="svn.advanced.locking.html" title="Locking">the section called “Locking”</a>.</p>
</div>
</div>
</div>
<div class="footnotes">
<br />
<hr style="width:100; text-align:left;margin-left: 0" />
<div id="ftn.idm481" class="footnote">
<p><a href="#idm481" class="para"><sup class="para">[5] </sup></a>The
term <span class="quote">“<span class="quote">working copy</span>”</span> can be generally applied to
any one file version's local instance. When most folks use
the term, though, they are referring to a whole directory tree
containing files and subdirectories managed by the version
control system.</p>
</div>
</div>
</div>
<div class="navfooter">
<hr />
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left"><a accesskey="p" href="svn.basic.html">Prev</a> </td>
<td width="20%" align="center">
<a accesskey="u" href="svn.basic.html">Up</a>
</td>
<td width="40%" align="right"> <a accesskey="n" href="svn.basic.in-action.html">Next</a></td>
</tr>
<tr>
<td width="40%" align="left" valign="top">Chapter 1. Fundamental Concepts </td>
<td width="20%" align="center">
<a accesskey="h" href="index.html">Home</a>
</td>
<td width="40%" align="right" valign="top"> Version Control the Subversion Way</td>
</tr>
</table>
</div>
<div xmlns="" id="vcws-footer">
<hr />
<img src="images/cc-by.png" style="float: right;" />
<p>You are reading <em>Version Control with Subversion</em> (for
Subversion 1.8), by Ben Collins-Sussman, Brian W. Fitzpatrick,
and C. Michael Pilato.</p>
<p>This work is licensed under
the <a href="http://creativecommons.org/licenses/by/2.0/">Creative Commons Attribution License v2.0</a>.</p>
<p>To submit comments, corrections, or other contributions to the
text, please visit <a href="http://www.svnbook.com/">http://www.svnbook.com/</a>.</p>
</div>
</body>
</html>
distrib
>
Mageia
>
6
>
x86_64
>
media
>
core-updates
>
by-pkgid
>
31498a559ceee64333612647bef4b546
>
files
>
49
