<?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>Strategies for Repository Deployment</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.reposadmin.html" title="Chapter 5. Repository Administration" />
<link rel="prev" href="svn.reposadmin.basics.html" title="The Subversion Repository, Defined" />
<link rel="next" href="svn.reposadmin.create.html" title="Creating and Configuring Your Repository" />
</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">Strategies for Repository Deployment</th>
</tr>
<tr>
<td width="20%" align="left"><a accesskey="p" href="svn.reposadmin.basics.html">Prev</a> </td>
<th width="60%" align="center">Chapter 5. Repository Administration</th>
<td width="20%" align="right"> <a accesskey="n" href="svn.reposadmin.create.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.reposadmin.planning"></a>Strategies for Repository Deployment</h2>
</div>
</div>
</div>
<p>Due largely to the simplicity of the overall design of the
Subversion repository and the technologies on which it relies,
creating and configuring a repository are fairly straightforward
tasks. There are a few preliminary decisions you'll want to
make, but the actual work involved in any given setup of a
Subversion repository is pretty basic, tending toward
mindless repetition if you find yourself setting up multiples of
these things.</p>
<p>Some things you'll want to consider beforehand, though, are:</p>
<div class="itemizedlist">
<ul class="itemizedlist" style="list-style-type: disc; ">
<li class="listitem">
<p>What data do you expect to live in your repository (or
repositories), and how will that data be organized?</p>
</li>
<li class="listitem">
<p>Where will your repository live, and how will it be
accessed?</p>
</li>
<li class="listitem">
<p>What types of access control do you need?</p>
</li>
</ul>
</div>
<p>In this section, we'll try to help you answer those
questions.</p>
<div class="sect2">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="svn.reposadmin.projects.chooselayout"></a>Planning Your Repository Organization</h3>
</div>
</div>
</div>
<p>While Subversion allows you to move around versioned files
and directories without any loss of information, and even
provides ways of moving whole sets of versioned history from
one repository to another, doing so can greatly disrupt the
workflow of those who access the repository often and come to
expect things to be at certain locations. So before creating
a new repository, try to peer into the future a bit; plan
ahead before placing your data under version control. By
conscientiously <span class="quote">“<span class="quote">laying out</span>”</span> your repository or
repositories and their versioned contents ahead of time, you
can prevent many future headaches.</p>
<p>Let's assume that as repository administrator, you will be
responsible for supporting the version control system for
several projects. Your first decision is whether to use a
single repository for multiple projects, or to give each
project its own repository, or some compromise of these
two.</p>
<p>There are benefits to using a single repository for
multiple projects, most obviously the lack of duplicated
maintenance. A single repository means that there is one set
of hook programs, one thing to routinely back up, one thing to
dump and load if Subversion releases an incompatible new
version, and so on. Also, you can move data between projects
easily, without losing any historical versioning
information.</p>
<p>The downside of using a single repository is that
different projects may have different requirements in terms of
the repository event triggers, such as needing to send commit
notification emails to different mailing lists, or having
different definitions about what does and does not constitute
a legitimate commit. These aren't insurmountable problems, of
course—it just means that all of your hook scripts have
to be sensitive to the layout of your repository rather than
assuming that the whole repository is associated with a single
group of people. Also, remember that Subversion uses
repository-global revision numbers. While those numbers don't
have any particular magical powers, some folks still don't
like the fact that even though no changes have been made to
their project lately, the youngest revision number for the
repository keeps climbing because other projects are actively
adding new revisions.<a href="#ftn.idm6108" class="footnote" id="idm6108"><sup class="footnote">[51]</sup></a></p>
<p>A middle-ground approach can be taken, too. For example,
projects can be grouped by how well they relate to each other.
You might have a few repositories with a handful of projects
in each repository. That way, projects that are likely to
want to share data can do so easily, and as new revisions are
added to the repository, at least the developers know that
those new revisions are at least remotely related to everyone
who uses that repository.</p>
<p>
<a id="idm6113" class="indexterm"></a>
After deciding how to organize your projects with respect
to repositories, you'll probably want to think about directory
hierarchies within the repositories themselves. Because
Subversion uses regular directory copies for branching and
tagging (see <a class="xref" href="svn.branchmerge.html" title="Chapter 4. Branching and Merging">Chapter 4, <em>Branching and Merging</em></a>), the
Subversion community recommends that you choose a repository
location for each project
root—the <span class="quote">“<span class="quote">topmost</span>”</span> directory
that contains data related to that project—and then
create three subdirectories beneath that root:
<code class="filename">trunk</code>, meaning the directory under which
the main project development occurs;
<code class="filename">branches</code>, which is a directory in which
to create various named branches of the main development line;
and <code class="filename">tags</code>, which is a collection of tree
snapshots that are created, and perhaps destroyed, but never
changed.<a href="#ftn.idm6120" class="footnote" id="idm6120"><sup class="footnote">[52]</sup></a></p>
<p>For example, your repository might look like this:</p>
<div class="informalexample">
<div class="literallayout">
<p><br />
/<br />
calc/<br />
trunk/<br />
tags/<br />
branches/<br />
calendar/<br />
trunk/<br />
tags/<br />
branches/<br />
spreadsheet/<br />
trunk/<br />
tags/<br />
branches/<br />
…<br />
</p>
</div>
</div>
<p>Note that it doesn't matter where in your repository each
project root is. If you have only one project per repository,
the logical place to put each project root is at the root of
that project's respective repository. If you have multiple
projects, you might want to arrange them in groups inside the
repository, perhaps putting projects with similar goals or
shared code in the same subdirectory, or maybe just grouping
them alphabetically. Such an arrangement might look
like this:</p>
<div class="informalexample">
<div class="literallayout">
<p><br />
/<br />
utils/<br />
calc/<br />
trunk/<br />
tags/<br />
branches/<br />
calendar/<br />
trunk/<br />
tags/<br />
branches/<br />
…<br />
office/<br />
spreadsheet/<br />
trunk/<br />
tags/<br />
branches/<br />
…<br />
</p>
</div>
</div>
<p>Lay out your repository in whatever way you see fit.
Subversion does not expect or enforce a particular layout—in
its eyes, a directory is a directory is a directory.
Ultimately, you should choose the repository arrangement that
meets the needs of the people who work on the projects that
live there.</p>
<p>In the name of full disclosure, though, we'll mention
another very common layout. In this layout, the
<code class="filename">trunk</code>, <code class="filename">tags</code>, and
<code class="filename">branches</code> directories live in the root
directory of your repository, and your projects are in
subdirectories beneath those, like so:</p>
<div class="informalexample">
<div class="literallayout">
<p><br />
/<br />
trunk/<br />
calc/<br />
calendar/<br />
spreadsheet/<br />
…<br />
tags/<br />
calc/<br />
calendar/<br />
spreadsheet/<br />
…<br />
branches/<br />
calc/<br />
calendar/<br />
spreadsheet/<br />
…<br />
</p>
</div>
</div>
<p>There's nothing particularly incorrect about such a
layout, but it may or may not seem as intuitive for your
users. Especially in large, multiproject situations with
many users, those users may tend to be familiar with only one
or two of the projects in the repository. But the
projects-as-branch-siblings approach tends to deemphasize project
individuality and focus on the entire set of projects as a
single entity. That's a social issue, though. We like our
originally suggested arrangement for purely practical
reasons—it's easier to ask about (or modify, or migrate
elsewhere) the entire history of a single project when there's
a single repository path that holds the entire
history—past, present, tagged, and branched—for
that project and that project alone.</p>
</div>
<div class="sect2">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="svn.reposadmin.basics.hosting"></a>Deciding Where and How to Host Your Repository</h3>
</div>
</div>
</div>
<p>Before creating your Subversion repository, an obvious
question you'll need to answer is where the thing is going to
live. This is strongly connected to myriad other
questions involving how the repository will be accessed (via a
Subversion server or directly), by whom (users behind your
corporate firewall or the whole world out on the open
Internet), what other services you'll be providing around
Subversion (repository browsing interfaces, email-based
commit notification, etc.), your data backup strategy, and so
on.</p>
<p>We cover server choice and configuration in
<a class="xref" href="svn.serverconfig.html" title="Chapter 6. Server Configuration">Chapter 6, <em>Server Configuration</em></a>, but the point we'd like
to briefly make here is simply that the answers to some of
these other questions might have implications that force your
hand when deciding where your repository will live. For
example, certain deployment scenarios might require accessing
the repository via a remote filesystem from multiple
computers, or using multiple repositories with syncronized
contents distributed geographically to permit more performant
access to that data by users around the globe. Addressing
each possible way to deploy Subversion is both impossible and
outside the scope of this book. We simply encourage you to
evaluate your options using these pages and other sources as
your reference material and to plan ahead.</p>
</div>
<div class="sect2">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="svn.reposadmin.basics.accesscontrol"></a>Controlling Access to Your Repository</h3>
</div>
</div>
</div>
<p>Access control in Subversion is almost entirely managed by
the Subversion server processes. We discuss the available
Subversion servers in <a class="xref" href="svn.serverconfig.html" title="Chapter 6. Server Configuration">Chapter 6, <em>Server Configuration</em></a>, and
explain path-based access control specifically in
<a class="xref" href="svn.serverconfig.pathbasedauthz.html" title="Path-Based Authorization">the section called “Path-Based Authorization”</a>. In
addition to those user-level access control questions, you'll also
want to ensure that your repository is accessible by the
programs on your hosting machine which need to access it.
Consider the OS-level user and group ownership that makes
sense for your repository. Once again, the information found
in <a class="xref" href="svn.serverconfig.html" title="Chapter 6. Server Configuration">Chapter 6, <em>Server Configuration</em></a> should be able to help
you make these decisions.</p>
</div>
<div class="footnotes">
<br />
<hr style="width:100; text-align:left;margin-left: 0" />
<div id="ftn.idm6108" class="footnote">
<p><a href="#idm6108" class="para"><sup class="para">[51] </sup></a>Whether founded in
ignorance or in poorly considered concepts about how to derive
legitimate software development metrics, global revision
numbers are a silly thing to fear,
and <span class="emphasis"><em>not</em></span> the kind of thing you should
weigh when deciding how to arrange your projects and
repositories.</p>
</div>
<div id="ftn.idm6120" class="footnote">
<p><a href="#idm6120" class="para"><sup class="para">[52] </sup></a>The <code class="filename">trunk</code>,
<code class="filename">tags</code>, and <code class="filename">branches</code>
trio is sometimes referred to as <span class="quote">“<span class="quote">the TTB
directories.</span>”</span></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.reposadmin.basics.html">Prev</a> </td>
<td width="20%" align="center">
<a accesskey="u" href="svn.reposadmin.html">Up</a>
</td>
<td width="40%" align="right"> <a accesskey="n" href="svn.reposadmin.create.html">Next</a></td>
</tr>
<tr>
<td width="40%" align="left" valign="top">The Subversion Repository, Defined </td>
<td width="20%" align="center">
<a accesskey="h" href="index.html">Home</a>
</td>
<td width="40%" align="right" valign="top"> Creating and Configuring Your Repository</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>
