Sophie

Sophie

distrib > Mandriva > 2008.1 > x86_64 > by-pkgid > 0b38be552745286620faf2138b9468d0 > files > 59

subversion-doc-1.4.6-5.1mdv2008.1.x86_64.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>Inside the Working Copy Administration Area</title><link rel="stylesheet" href="styles.css" type="text/css" /><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><link rel="start" href="index.html" title="Version Control with Subversion" /><link rel="up" href="svn.developer.html" title="Chapter 8. Embedding Subversion" /><link rel="prev" href="svn.developer.layerlib.html" title="Layered Library Design" /><link rel="next" href="svn.developer.usingapi.html" title="Using the APIs" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Inside the Working Copy Administration Area</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="svn.developer.layerlib.html">Prev</a> </td><th width="60%" align="center">Chapter 8. Embedding Subversion</th><td width="20%" align="right"> <a accesskey="n" href="svn.developer.usingapi.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="svn.developer.insidewc"></a>Inside the Working Copy Administration Area</h2></div></div></div><p>As we mentioned earlier, each directory of a Subversion
      working copy contains a special subdirectory called
      <code class="filename">.svn</code> which houses administrative data about
      that working copy directory.  Subversion uses the information in
      <code class="filename">.svn</code> to keep track of things like:</p><div class="itemizedlist"><ul type="disc"><li><p>Which repository location(s) are represented by the
          files and subdirectories in the working copy
          directory.</p></li><li><p>What revision of each of those files and directories are
          currently present in the working copy.</p></li><li><p>Any user-defined properties that might be attached
          to those files and directories.</p></li><li><p>Pristine (un-edited) copies of the working copy
          files.</p></li></ul></div><p>The Subversion working copy administration area's layout and
      contents are considered implementation details not really
      intended for human consumption.  Developers are encouraged to
      use Subversion's public APIs, or the tools that Subversion provides, to access and
      manipulate the working copy data, instead of directly reading
      or modifying those files.  The file formats employed by the working
      copy library for its administrative data do change from time to
      time—a fact that the public APIs do a great job of
      hiding from the average user.  In this section, we
      expose some of these implementation details sheerly to appease
      your overwhelming curiosity.</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="svn.developer.insidewc.entries"></a>The Entries File</h3></div></div></div><p>Perhaps the single most important file in the
        <code class="filename">.svn</code> directory is the
        <code class="filename">entries</code> file.  It
        contains the bulk of the administrative
        information about the versioned items in a working copy
        directory.  It is this one file which tracks the repository
        URLs, pristine revision, file checksums, pristine text and
        property timestamps, scheduling and conflict state
        information, last-known commit information (author, revision,
        timestamp), local copy history—practically everything
        that a Subversion client is interested in knowing about a
        versioned (or to-be-versioned) resource!</p><p>Folks familiar with CVS's administrative directories will
        have recognized at this point that Subversion's
        <code class="filename">.svn/entries</code> file serves the purposes of,
        among other things, CVS's <code class="filename">CVS/Entries</code>,
        <code class="filename">CVS/Root</code>, and
        <code class="filename">CVS/Repository</code> files combined.</p><p>The format of the <code class="filename">.svn/entries</code> file
        has changed over time.  Originally an XML file, it now uses a
        custom—though still human-readable—file format.
        While XML was a great choice for early developers of
        Subversion who were frequently debugging the file's contents
        (and Subversion's behavior in light of them), the need for
        easy developer debugging has diminished as Subversion has
        matured, and has been replaced by the user's need for snappier
        performance.  Be aware that Subversion's working copy library
        automatically upgrades working copies from one format to
        another—it reads the old formats, and writes the
        new—which saves you the hassle of checking out a new
        working copy, but can also complicate situations where
        different versions of Subversion might be trying to use the
        same working copy.</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="svn.developer.insidewc.base-and-props"></a>Pristine Copies and Property Files</h3></div></div></div><p>As mentioned before, the <code class="filename">.svn</code>
        directory also holds the pristine “<span class="quote">text-base</span>”
        versions of files.  Those can be found in
        <code class="filename">.svn/text-base</code>.  The benefits of these
        pristine copies are multiple—network-free checks for
        local modifications and difference reporting, network-free
        reversion of modified or missing files, more efficient transmission
        of changes to the server—but comes at the cost of having
        each versioned file stored at least twice on disk.  These
        days, this seems to be a negligible penalty for most files.
        However, the situation gets uglier as the size of your
        versioned files grows.  Some attention is being given to
        making the presence of the “<span class="quote">text-base</span>” an option.
        Ironically though, it is as your versioned files' sizes get
        larger that the existence of the “<span class="quote">text-base</span>”
        becomes more crucial—who wants to transmit a huge file
        across a network just because they want to commit a tiny
        change to it?</p><p>Similar in purpose to the “<span class="quote">text-base</span>” files
        are the property files and their pristine
        “<span class="quote">prop-base</span>” copies, located in
        <code class="filename">.svn/props</code> and
        <code class="filename">.svn/prop-base</code> respectively.  Since
        directories can have properties, too, there are also
        <code class="filename">.svn/dir-props</code> and
        <code class="filename">.svn/dir-prop-base</code> files.</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="svn.developer.layerlib.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="svn.developer.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="svn.developer.usingapi.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Layered Library Design </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Using the APIs</td></tr></table></div></body></html>