Sophie

Sophie

distrib > Mageia > 6 > i586 > media > core-updates > by-pkgid > d32d95698a59acd37b394f83dfc217c6 > files > 54

subversion-doc-1.9.7-1.mga6.i586.rpm

<?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>Branch Maintenance</title>
    <link rel="stylesheet" type="text/css" href="styles.css" />
    <meta name="generator" content="DocBook XSL Stylesheets V1.76.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.branchmerge.html" title="Chapter 4. Branching and Merging" />
    <link rel="prev" href="svn.branchmerge.tags.html" title="Tags" />
    <link rel="next" href="svn.branchmerge.commonpatterns.html" title="Common Branching Patterns" />
  </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">Branch Maintenance</th>
        </tr>
        <tr>
          <td width="20%" align="left"><a accesskey="p" href="svn.branchmerge.tags.html">Prev</a> </td>
          <th width="60%" align="center">Chapter 4. Branching and Merging</th>
          <td width="20%" align="right"> <a accesskey="n" href="svn.branchmerge.commonpatterns.html">Next</a></td>
        </tr>
      </table>
      <hr />
    </div>
    <div class="sect1" title="Branch Maintenance">
      <div class="titlepage">
        <div>
          <div>
            <h2 class="title" style="clear: both"><a id="svn.branchmerge.maint"></a>Branch Maintenance</h2>
          </div>
        </div>
      </div>
      <p>You may have noticed by now that Subversion is extremely
      flexible.  Because it implements branches and tags with the same
      underlying mechanism (directory copies), and because branches
      and tags appear in normal filesystem space, many people find
      Subversion intimidating.  It's almost <span class="emphasis"><em>too</em></span>
      flexible.  In this section, we'll offer some suggestions for
      arranging and managing your data over time.</p>
      <div class="sect2" title="Repository Layout">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title"><a id="svn.branchmerge.maint.layout"></a>Repository Layout</h3>
            </div>
          </div>
        </div>
        <p>There are some standard, recommended ways to organize the
        contents of a repository.  Most people create a
        <code class="filename">trunk</code> directory to hold the <span class="quote">“<span class="quote">main
        line</span>”</span> of development, a <code class="filename">branches</code>
        directory to contain branch copies, and
        a <code class="filename">tags</code> directory to contain tag copies.
        If a repository holds only one project, often people create
        these top-level directories:</p>
        <div class="informalexample">
          <div class="literallayout">
            <p><br />
/<br />
   trunk/<br />
   branches/<br />
   tags/<br />
</p>
          </div>
        </div>
        <p>If a repository contains multiple projects, admins
        typically index their layout by project.  See <a class="xref" href="svn.reposadmin.planning.html#svn.reposadmin.projects.chooselayout" title="Planning Your Repository Organization">the section called “Planning Your Repository Organization”</a> to read more about
        <span class="quote">“<span class="quote">project roots</span>”</span>, but here's an example of such a
        layout:</p>
        <div class="informalexample">
          <div class="literallayout">
            <p><br />
/<br />
   paint/<br />
      trunk/<br />
      branches/<br />
      tags/<br />
   calc/<br />
      trunk/<br />
      branches/<br />
      tags/<br />
</p>
          </div>
        </div>
        <p>Of course, you're free to ignore these common layouts.
        You can create any sort of variation, whatever works best for
        you or your team.  Remember that whatever you choose, it's not
        a permanent commitment.  You can reorganize your repository at
        any time.  Because branches and tags are ordinary directories,
        the <span class="command"><strong>svn move</strong></span> command can move or rename
        them however you wish.  Switching from one layout to another
        is just a matter of issuing a series of server-side moves; if
        you don't like the way things are organized in the repository,
        just juggle the directories around.</p>
        <p>Remember, though, that while moving directories is
        easy to do, you need to be considerate of other users as well.
        Your juggling can disorient users with existing
        working copies.  If a user has a working copy of a particular
        repository directory and your <span class="command"><strong>svn move</strong></span>
        subcommand removes the path from the latest revision, then
        when the user next runs <span class="command"><strong>svn update</strong></span>, she is
        told that her working copy represents a path that no
        longer exists.  She is then forced to <span class="command"><strong>svn
        switch</strong></span> to the new location.</p>
      </div>
      <div class="sect2" title="Data Lifetimes">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title"><a id="svn.branchmerge.maint.lifetime"></a>Data Lifetimes</h3>
            </div>
          </div>
        </div>
        <p>Another nice feature of Subversion's model is that
        branches and tags can have finite lifetimes, just like any
        other versioned item.  For example, suppose you eventually
        finish all your work on your personal branch of the
        <code class="filename">calc</code> project.  After merging all of your
        changes back into <code class="filename">/calc/trunk</code>, there's
        no need for your private branch directory to stick around
        anymore:</p>
        <div class="informalexample">
          <pre class="screen">
$ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch \
             -m "Removing obsolete branch of calc project."

Committed revision 474.
</pre>
        </div>
        <div class="tip" title="Tip" style="margin-left: 0.5in; margin-right: 0.5in;">
          <table border="0" summary="Tip">
            <tr>
              <td rowspan="2" align="center" valign="top" width="25">
                <img alt="[Tip]" src="images/tip.png" />
              </td>
              <th align="left">Tip</th>
            </tr>
            <tr>
              <td align="left" valign="top">
                <p>Recall from the previous section that if the repository
          location your working copy refers to is deleted, then when
          you try to update you will receive an error:</p>
                <div class="informalexample">
                  <pre class="screen">
$ svn up
Updating '.':
svn: E160005: Target path '/calc/branches/my-calc-branch' does not exist
</pre>
                </div>
                <p>All you need to do in this situation is switch your working
          copy to a location that still exits:</p>
                <div class="informalexample">
                  <pre class="screen">
$ svn sw ^/calc/trunk
D    src/whole.c
 U   src/real.c
A    src/integer.c
 U   .
Updated to revision 474.
</pre>
                </div>
              </td>
            </tr>
          </table>
        </div>
        <p>And now your branch is gone.  Of course, it's not really
        gone: the directory is simply missing from the
        <code class="literal">HEAD</code> revision, no longer distracting
        anyone.  If you use <span class="command"><strong>svn checkout</strong></span>,
        <span class="command"><strong>svn switch</strong></span>, or <span class="command"><strong>svn list</strong></span>
        to examine an earlier revision, you can still see
        your old branch.</p>
        <p>If browsing your deleted directory isn't enough, you can
        always bring it back.  Resurrecting data is very easy in
        Subversion.  If there's a deleted directory (or file) that
        you'd like to bring back into <code class="literal">HEAD</code>, simply
        use <span class="command"><strong>svn copy</strong></span> to copy it from the old
        revision:</p>
        <div class="informalexample">
          <pre class="screen">
$ svn copy ^/calc/branches/my-calc-branch@473 \
           ^/calc/branches/my-calc-branch \
           -m "Restore my-calc-branch."

Committed revision 475.
</pre>
        </div>
        <p>In our example, your personal branch had a relatively
        short lifetime: you may have created it to fix a bug or
        implement a new feature.  When your task is done, so is the
        branch.  In software development, though, it's also common to
        have two <span class="quote">“<span class="quote">main</span>”</span> branches running side by side for
        very long periods.  For example, suppose it's time to release
        a stable version of the <code class="filename">calc</code> project to the
        public, and you know it's going to take a couple of months to
        shake bugs out of the software.  You don't want people to add
        new features to the project, but you don't want to tell all
        developers to stop programming either.  So instead, you create
        a <span class="quote">“<span class="quote">stable</span>”</span> branch of the software that won't
        change much:</p>
        <div class="informalexample">
          <pre class="screen">
$ svn copy ^/calc/trunk ^/calc/branches/stable-1.0 \
           -m "Creating stable branch of calc project."

Committed revision 476.
</pre>
        </div>
        <p>And now developers are free to continue adding
        cutting-edge (or experimental) features to
        <code class="filename">/calc/trunk</code>, and you can declare a
        project policy that only bug fixes are to be committed to
        <code class="filename">/calc/branches/stable-1.0</code>.  That is, as
        people continue to work on the trunk, a human selectively
        cherrypicks bug fixes over to the stable branch.  Even after the
        stable branch has shipped, you'll probably continue to
        maintain the branch for a long time—that is, as long
        as you continue to support that release for customers.  We'll
        discuss this more in the next section.</p>
      </div>
    </div>
    <div class="navfooter">
      <hr />
      <table width="100%" summary="Navigation footer">
        <tr>
          <td width="40%" align="left"><a accesskey="p" href="svn.branchmerge.tags.html">Prev</a> </td>
          <td width="20%" align="center">
            <a accesskey="u" href="svn.branchmerge.html">Up</a>
          </td>
          <td width="40%" align="right"> <a accesskey="n" href="svn.branchmerge.commonpatterns.html">Next</a></td>
        </tr>
        <tr>
          <td width="40%" align="left" valign="top">Tags </td>
          <td width="20%" align="center">
            <a accesskey="h" href="index.html">Home</a>
          </td>
          <td width="40%" align="right" valign="top"> Common Branching Patterns</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>