[svnbook commit] r2649 - trunk/src/ru/book
dmitriy
noreply at red-bean.com
Mon Feb 5 09:15:15 CST 2007
Author: dmitriy
Date: Mon Feb 5 09:15:14 2007
New Revision: 2649
Added:
trunk/src/ru/book/index.xml (props changed)
- copied unchanged from r2601, /trunk/src/en/book/index.xml
Modified:
trunk/src/ru/book/app-quickstart.xml (props changed)
trunk/src/ru/book/app-svn-for-cvs-users.xml (contents, props changed)
trunk/src/ru/book/app-third-party-tools.xml (props changed)
trunk/src/ru/book/app-webdav.xml (contents, props changed)
trunk/src/ru/book/book.xml (contents, props changed)
trunk/src/ru/book/ch-advanced-topics.xml (contents, props changed)
trunk/src/ru/book/ch-basic-usage.xml (contents, props changed)
trunk/src/ru/book/ch-branching-and-merging.xml (props changed)
trunk/src/ru/book/ch-customizing-svn.xml (contents, props changed)
trunk/src/ru/book/ch-developer-info.xml (contents, props changed)
trunk/src/ru/book/ch-fundamental-concepts.xml (contents, props changed)
trunk/src/ru/book/ch-preface.xml (contents, props changed)
trunk/src/ru/book/ch-reference.xml (contents, props changed)
trunk/src/ru/book/ch-repository-admin.xml (props changed)
trunk/src/ru/book/ch-server-configuration.xml (contents, props changed)
trunk/src/ru/book/copyright.xml (props changed)
trunk/src/ru/book/foreword.xml (props changed)
trunk/src/ru/book/styles.css (props changed)
Log:
Book Russian. Merge with changes from r2580:r2601 of the src/en/book. More detail in logs for corresponding revisions.
Modified: trunk/src/ru/book/app-svn-for-cvs-users.xml
==============================================================================
--- trunk/src/ru/book/app-svn-for-cvs-users.xml (original)
+++ trunk/src/ru/book/app-svn-for-cvs-users.xml Mon Feb 5 09:15:14 2007
@@ -301,7 +301,7 @@
C Resource has Conflicts (changes have not been completely merged
between the repository and working copy version)
X Resource is eXternal to this working copy (may come from another
- repository). See <xref linkend="svn.advanced.props.special.externals" />
+ repository). See <xref linkend="svn.advanced.externals" />
? Resource is not under version control
! Resource is missing or incomplete (removed by another tool than
Subversion)
Modified: trunk/src/ru/book/app-webdav.xml
==============================================================================
--- trunk/src/ru/book/app-webdav.xml (original)
+++ trunk/src/ru/book/app-webdav.xml Mon Feb 5 09:15:14 2007
@@ -419,7 +419,7 @@
repository via autoversioning. The module looks at the file's
named extension and possibly the contents as well; if the file
matches some common patterns, then the the
- file's <literal>svn;mime-type</literal> property will be set
+ file's <literal>svn:mime-type</literal> property will be set
automatically.</para>
</sect1>
@@ -602,7 +602,7 @@
in Java. It's under a free Apache-like license and is
available at <ulink url="http://www.ics.uci.edu/~webdav/"/>.
DAV Explorer does everything cadaver does, but has the
- advantages of being portable and being more user-friendly GUI
+ advantages of being portable and being a more user-friendly GUI
application. It's also one of the first clients to support
the new WebDAV Access Control Protocol (RFC 3744).</para>
@@ -701,7 +701,7 @@
algorithm seems to work consistently on every system. The
general consensus of the WebDAV community is that you should
avoid the new Web Folders implementation and use the old one
- instead, and that if you need real a real filesystem-level
+ instead, and that if you need a real filesystem-level
client for Windows XP, then use a third-party program like
WebDrive or NetDrive.</para>
@@ -721,7 +721,7 @@
<para>Nautilus is the official file manager/browser for the
GNOME desktop (<ulink url="http://www.gnome.org"/>), and
- Konqueror is the manager/browser for KDE desktop (<ulink
+ Konqueror is the manager/browser for the KDE desktop (<ulink
url="http://www.kde.org"/>). Both of these applications have
an explorer-level WebDAV client built-in, and operate just
fine against an autoversioning repository.</para>
@@ -763,7 +763,7 @@
<title>WebDrive, NetDrive</title>
<para>Both WebDrive and NetDrive are excellent commercial
- products which allows a WebDAV share to be attached as drive
+ products which allow a WebDAV share to be attached as drive
letters in Windows. We've had nothing but success with
these products. At the time of writing, WebDrive can be
purchased from South River Technologies (<ulink
@@ -784,14 +784,19 @@
filesystem-level WebDAV client. From the Finder, select the
<guimenuitem>Connect to Server</guimenuitem> item from the
<guimenu>Go menu</guimenu>. Enter a WebDAV URL, and it
- appears as a disk on the desktop, just like any other mounted
- volume.<footnote><para>From the Darwin terminal, one can also
- run <literal>mount -t webdav URL
- /mountpoint</literal></para></footnote>.</para>
+ appears as a disk on the desktop, just like any other
+ mounted volume. You can also mount a WebDAV share from the
+ Darwin terminal by using the <literal>webdav</literal>
+ filesystem type with the <command>mount</command> command:</para>
+
+ <screen>
+$ mount -t webdav http://svn.example.com/repos/project /some/mountpoint
+$
+</screen>
<para>Note that if your mod_dav_svn is older than version 1.2,
OS X will refuse to mount the share as read-write; it will
- appear as read-only. This is because the OS X insists on
+ appear as read-only. This is because OS X insists on
locking support for read-write shares, and the ability to lock
files first appeared in Subversion 1.2.</para>
Modified: trunk/src/ru/book/book.xml
==============================================================================
--- trunk/src/ru/book/book.xml (original)
+++ trunk/src/ru/book/book.xml Mon Feb 5 09:15:14 2007
@@ -19,6 +19,7 @@
<!ENTITY appc SYSTEM "app-webdav.xml">
<!ENTITY appd SYSTEM "app-third-party-tools.xml">
<!ENTITY license SYSTEM "copyright.xml">
+<!ENTITY index SYSTEM "index.xml">
]>
<!-- @ENGLISH {{{
@@ -33,8 +34,9 @@
<bookinfo>
<!-- @ENGLISH {{{
- <subtitle>For Subversion 1.3</subtitle>
+ <subtitle>For Subversion 1.4</subtitle>
@ENGLISH }}} -->
+ <subtitle>Для Subversion 1.4</subtitle>
<!-- Using revnumber would be more appropriate, but our stylesheets -->
<!-- don't seem to render it. -->
@@ -75,6 +77,7 @@
<year>2004</year>
<year>2005</year>
<year>2006</year>
+ <year>2007</year>
<holder>Ben Collins-Sussman</holder>
<holder>Brian W. Fitzpatrick</holder>
<holder>C. Michael Pilato</holder>
@@ -115,6 +118,7 @@
&appc;
&appd;
&license;
+ &index;
</book>
<!--
Modified: trunk/src/ru/book/ch-advanced-topics.xml
==============================================================================
--- trunk/src/ru/book/ch-advanced-topics.xml (original)
+++ trunk/src/ru/book/ch-advanced-topics.xml Mon Feb 5 09:15:14 2007
@@ -19,19 +19,6 @@
you to run the <command>svn status</command> command almost
unconsciously. For all intents and purposes, you are ready to
use Subversion in a typical environment.</para>
-
- <para>But the Subversion feature set doesn't stop at <quote>common
- version control operations</quote>.</para>
-
- <para>This chapter highlights some of Subversion's features that
- aren't quite so regularly used. In it, we will discuss
- Subversion's property (or <quote>metadata</quote>) support, and
- how to modify Subversion's default behaviors by tweaking its
- run-time configuration area. We will describe how you can use
- externals definitions to instruct Subversion to pull data from
- multiple repositories. We'll cover in detail some of the
- additional client- and server-side tools that are part of the
- Subversion distribution.</para>
@ENGLISH }}} -->
<para>Если эту книгу вы читали главу за главой, от начала до
конца, то к настоящему моменту должны иметь достаточно знаний
@@ -44,46 +31,347 @@
применять Subversion в большинстве возможных типовых
ситуаций.</para>
- <para>Однако предоставляемая Subversion функциональность не
- ограничивается <quote>типовыми операциями управления
- версиями</quote>.</para>
-
<!-- @ENGLISH {{{
- <para>This chapter highlights some of Subversion's features that
- aren't quite so regularly used. In it, we will discuss
- Subversion's property (or <quote>metadata</quote>) support, and
- how to modify Subversion's default behaviors by tweaking its
- run-time configuration area. We will describe how you can use
- externals definitions to instruct Subversion to pull data from
- multiple repositories. We'll cover in detail some of the
- additional client- and server-side tools that are part of the
- Subversion distribution.</para>
-
- <para>Before reading this chapter, you should be familiar with the
- basic file and directory versioning capabilities of Subversion.
- If you haven't already read about those, or if you need a
- refresher, we recommend that you check out <xref
- linkend="svn.basic" /> and <xref linkend="svn.tour" />. Once
- you've mastered the basics and consumed this chapter, you'll be
- a Subversion power-user!
+ <para>But the Subversion feature set doesn't stop at <quote>common
+ version control operations</quote>. It has other bits of
+ functionality that extend beyond basic file and directory
+ versioning; beyond just sending and receiving changes to and from
+ a central repository.</para>
+ @ENGLISH }}} -->
+ <para>Однако предоставляемый Subversion набор возможностей не
+ ограничивается <quote>типовыми операциями управления
+ версиями</quote>. У Subversion есть функыональнось, выходящая за пределы
+ обычного версионирования файлов и директорий; идущая дальше простой
+ отправки и получения разлиций в и из центрального хранилища.
</para>
+ <!-- @ENGLISH {{{
+ <para>This chapter highlights some of Subversion's features that,
+ while important, aren't part of the typical user's daily routine.
+ It assumes that you are familiar with Subversion's basic file and
+ directory versioning capabilities. If you aren't, you'll want to
+ first read <xref linkend="svn.basic" /> and <xref
+ linkend="svn.tour" />. Once you've mastered those basics and
+ consumed this chapter, you'll be a Subversion power-user!</para>
@ENGLISH }}} -->
- <para>Эта глава рассказывает о не часто используемых возможностях
- Subversion. В ней мы рассмотрим поддержку свойств (или
- <quote>метаданных</quote>) и способы изменения стандартного поведения
- Subversion изменяя ее параметры времени выполнения. Мы расскажем
- как используя внешние зависимости заставить Subversion получать
- информацию из нескольких хранилищ. Подробно рассмотрим клиентские и
- серверные инструменты, входящие в поставку Subversion.</para>
-
- <para>Перед чтением этой главы, необходимо хорошо представлять
+ <para>Эта глава рассказывает о тех возможностях Subversion, которые,
+ не смотря на свою важность, не используются в обычном рутинном рабочем
+ цикле. Перед чтением этой главы, необходимо хорошо представлять
механизмы версионированния файлов и директорий в Subversion.
- Если вы еще этого не прочитали или просто хотите освежить в памяти
- эту информацию, рекомендуем просмотреть <xref linkend="svn.basic" />
- и <xref linkend="svn.tour" />. После того как вы овладеете
- основами и примами, рассмотренными в этой главе, вы станете продвинутым
- пользователем Subversion!</para>
+ Если вы этого не знаете, пред тем как продолжить, вам необходимо
+ прочитать <xref linkend="svn.basic" /> и <xref linkend="svn.tour" />.
+ После того как вы овладеете основами и примами, рассмотренными в этой
+ главе, вы станете продвинутым пользователем Subversion!</para>
+
+ <!-- ================================================================= -->
+ <!-- ================================================================= -->
+ <!-- ================================================================= -->
+ <sect1 id="svn.advanced.pegrevs">
+ <title>Peg and Operative Revisions</title>
+
+ <para>We make use of the ability to copy, move, rename, and
+ completely replace files and directories on our computers all
+ the time. And your version control system shouldn't get in the
+ way of your doing these things with your version-controlled
+ files and directories, either. Subversion's file management
+ support is quite liberating, affording almost as much
+ flexibility for versioned files as you'd expect when
+ manipulating your unversioned ones. But that flexibility means
+ that across the lifetime of your repository, a given versioned
+ resource might have many paths, and a given path might represent
+ several entirely different versioned resources. And this
+ introduces a certain level of complexity to your interactions
+ with those paths and resources.</para>
+
+ <para>Subversion is pretty smart about noticing when an object's
+ version history includes such <quote>changes of address</quote>.
+ For example, if you ask for the revision history log of a
+ particular file that was renamed last week, Subversion happily
+ provides all those logs—the revision in which the rename
+ itself happened, plus the logs of relevant revisions both before
+ and after that rename. So, most of the time, you don't even
+ have to think about such things. But occasionally, Subversion
+ needs your help to clear up ambiguities.</para>
+
+ <para>The simplest example of this occurs when a directory or file
+ is deleted from version control, and then a new directory or
+ file is created with the same name and added to version control.
+ Clearly the thing you deleted and the thing you later added
+ aren't the same thing. They merely happen to have had the same
+ path, <filename>/trunk/object</filename> for example. What,
+ then, does it mean to ask Subversion about the history of
+ <filename>/trunk/object</filename>? Are you asking about the
+ thing currently at that location, or the old thing you deleted
+ from that location? Are you asking about the operations that
+ have happened to <emphasis>all</emphasis> the objects that have
+ ever lived at that path? Clearly, Subversion needs a hint about
+ what you really want.</para>
+
+ <para>And thanks to moves, versioned resource history can get far
+ more twisted than that, even. For example, you might have a
+ directory named <filename>concept</filename>, containing some
+ nascent software project you've been toying with. Eventually,
+ though, that project matures to the point that the idea seems to
+ actually have some wings, so you do the unthinkable and decide
+ to give the project a name.
+ <footnote>
+ <para><quote>You're not supposed to name it. Once you name it,
+ you start getting attached to it.</quote> — Mike
+ Wazowski</para>
+ </footnote>
+ Let's say you called your software Frabnaggilywort. At this
+ point, it makes sense to rename the directory to reflect the
+ project's new name, so <filename>concept</filename> is renamed
+ to <filename>frabnaggilywort</filename>. Life goes on,
+ Frabnaggilywort releases a 1.0 version, and is downloaded and
+ used daily by hordes of people aiming to improve their
+ lives.</para>
+
+ <para>It's a nice story, really, but it doesn't end there.
+ Entrepreneur that you are, you've already got another think in
+ the tank. So you make a new directory,
+ <filename>concept</filename>, and the cycle begins again. In
+ fact, the cycle begins again many times over the years, each
+ time starting with that old <filename>concept</filename>
+ directory, then sometimes seeing that directory renamed as the
+ idea cures, sometimes seeing it deleted when you scrap the idea.
+ Or, to get really sick, maybe you rename
+ <filename>concept</filename> to something else for a while, but
+ later rename the thing back to <filename>concept</filename> for
+ some reason.</para>
+
+ <para>When scenarios like these occur, attempting to instruct
+ Subversion to work with these re-used paths can be a little like
+ instructing a motorist in Chicago's West Suburbs to drive east
+ down Roosevelt Road and turn left onto Main Street. In a mere
+ twenty minutes, you can cross <quote>Main Street</quote> in
+ Wheaton, Glen Ellyn, and Lombard. And no, they aren't the same
+ street. Our motorist—and our Subversion—need a
+ little more detail in order to do the right thing.</para>
+
+ <para>In version 1.1, Subversion introduced a way for you to tell
+ it exactly which Main Street you meant. It's called the
+ <firstterm>peg revision</firstterm>, and it is a revision
+ provided to Subversion for the sole purpose of identifying a
+ unique line of history. Because at most one versioned resource
+ may occupy a path at any given time—or, more precisely, in
+ any one revision—the combination of a path and a peg
+ revision is all that is needed to refer to a specific line of
+ history. Peg revisions are specified to the Subversion
+ command-line client using <firstterm>at syntax</firstterm>, so
+ called because the syntax involves appending an <quote>at
+ sign</quote> (<literal>@</literal>) and the peg revision to the
+ end of the path with which the revision is associated.</para>
+
+ <para>But what of the <option>--revision (-r)</option> of which
+ we've spoken so much in this book? That revision (or set of
+ revisions) is called the <firstterm>operative
+ revision</firstterm> (or <firstterm>operative revision
+ range</firstterm>). Once a particular line of history has been
+ identified using a path and peg revision, Subversion performs
+ the requested operation using the operative revision(s). To map
+ this to our Chicagoland streets analogy, if we are told to go to
+ 606 N. Main Street in Wheaton,
+ <footnote>
+ <para>606 N. Main Street, Wheaton, Illinois, is the home of
+ the Wheaton History Center. Get it—<quote>History
+ Center</quote>? It seemed appropriate….</para>
+ </footnote>
+ we can think of <quote>Main Street</quote> as our path and
+ <quote>Wheaton</quote> as our peg revision. These two pieces of
+ information identify a unique path which can travelled (north or
+ south on Main Street), and will keep us from travelling up and
+ down the wrong Main Street in search of our destination. Now we
+ throw in <quote>606 N.</quote> as our operative revision, of
+ sorts, and we know <emphasis>exactly</emphasis> where to
+ go.</para>
+
+ <sidebar>
+ <title>The "peg-revision" algorithm</title>
+
+ <para>The Subversion command-line performs the peg-revision
+ algorithm basically any time it needs to resolve possible
+ ambiguities in the paths and revisions provided to it. Here's
+ an example of such an invocation for the purposes of
+ illustrating that algorithm.</para>
+
+ <screen>
+$ svn <replaceable>command</replaceable> -r <replaceable>OPERATIVE-REV</replaceable> item@<replaceable>PEG-REV</replaceable>
+</screen>
+
+ <para>The algorithm has three simple steps:</para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>Locate <replaceable>item</replaceable> in the revision
+ identified by <replaceable>PEG-REV</replaceable>. There
+ can be only one such object.</para>
+ </listitem>
+
+ <listitem>
+ <para>Trace the object's history backwards (through any
+ possible renames) to its ancestor in the
+ revision <replaceable>OPERATIVE-REV</replaceable>.</para>
+ </listitem>
+
+ <listitem>
+ <para>Perform the requested action on that ancestor,
+ wherever it is located, or whatever its name might
+ be or have been at that time.</para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>Note that even when you don't explicitly supply a peg
+ revision or operative revision, they are still present. For
+ your convenience, the default peg revision is
+ <literal>BASE</literal> for working copy items and
+ <literal>HEAD</literal> for repository URLs. And when no
+ operative revision is provided, it defaults to being the same
+ revision as the peg revision.</para>
+
+ </sidebar>
+
+ <para>Say that long ago we created our repository, and in revision 1
+ added our first <filename>concept</filename> directory, plus an
+ <filename>IDEA</filename> file in that directory talking about
+ the concept. After several revisions in which real code was
+ added and tweaked, we, in revision 20, renamed this directory to
+ <filename>frabnaggilywort</filename>. By revision 27, we had a
+ new concept, a new <filename>concept</filename> directory to
+ hold it, and a new <filename>IDEA</filename> file to describe
+ it. And then five years and twenty thousand revisions flew by,
+ just like they would in any good romance story.</para>
+
+ <para>Now, years later, we wonder what the
+ <filename>IDEA</filename> file looked like back in revision 1.
+ But Subversion needs to know if we are asking about how the
+ <emphasis>current</emphasis> file looked back in revision 1, or
+ are we asking for the contents of whatever file lived at
+ <filename>concepts/IDEA</filename> in revision 1? Certainly
+ those questions have different answers, and because of peg
+ revisions, you can ask either of them. To find out how the
+ current <filename>IDEA</filename> file looked in that old
+ revision, you run:</para>
+
+ <screen>
+$ svn cat -r 1 concept/IDEA
+subversion/libsvn_client/ra.c:775: (apr_err=20014)
+svn: Unable to find repository location for 'concept/IDEA' in revision 1
+</screen>
+
+ <para>Of course, in this example, the current
+ <filename>IDEA</filename> file didn't exist yet in revision 1,
+ so Subversion gives an error. The command above is shorthand
+ for a longer notation which explicitly lists a peg revision.
+ The expanded notation is:</para>
+
+ <screen>
+$ svn cat -r 1 concept/IDEA at BASE
+subversion/libsvn_client/ra.c:775: (apr_err=20014)
+svn: Unable to find repository location for 'concept/IDEA' in revision 1
+</screen>
+
+ <para>And when executed, it has the expected results. Peg revisions
+ generally default to a value of <literal>BASE</literal> (the
+ revision currently present in the working copy) when applied to
+ working copy paths, and of <literal>HEAD</literal> when applied
+ to URLs.</para>
+
+ <para>The perceptive reader is probably wondering at this point if
+ the peg revision syntax causes problems for working copy paths
+ or URLs that actually have at signs in them. After
+ all, how does <command>svn</command> know whether
+ <literal>news at 11</literal> is the name of a directory in my
+ tree, or just a syntax for <quote>revision 11 of
+ <filename>news</filename></quote>? Thankfully, while
+ <command>svn</command> will always assume the latter, there is a
+ trivial workaround. You need only append an at sign to the
+ end of the path, such as <literal>news at 11@</literal>.
+ <command>svn</command> only cares about the last at sign in
+ the argument, and it is not considered illegal to omit a literal
+ peg revision specifier after that at sign. This workaround
+ even applies to paths that end in an at sign—you would
+ use <literal>filename@@</literal> to talk about a file named
+ <filename>filename@</filename>.</para>
+
+ <para>Let's ask the other question, then—in revision 1, what
+ were the contents of whatever file occupied the address
+ <filename>concepts/IDEA</filename> at the time? We'll use an
+ explicit peg revision to help us out.</para>
+
+ <screen>
+$ svn cat concept/IDEA at 1
+The idea behind this project is to come up with a piece of software
+that can frab a naggily wort. Frabbing naggily worts is tricky
+business, and doing it incorrectly can have serious ramifications, so
+we need to employ over-the-top input validation and data verification
+mechanisms.
+</screen>
+
+ <para>Notice that we didn't provide an operative revision this
+ time. That's because when no operative revision is specified,
+ Subversion assumes a default operative revision that's the same
+ as the peg revision.</para>
+
+ <para>As you can see, the output from our operation appears to be
+ correct. The text even mentions frabbing naggily worts, so this
+ is almost certainly the file which describes the software now
+ called Frabnaggilywort. In fact, we can verify this using the
+ combination of an explicit peg revision and explicit operative
+ revision. We know that in <literal>HEAD</literal>, the
+ Frabnaggilywort project is located in the
+ <filename>frabnaggilywort</filename> directory. So we specify
+ that we want to see how the line of history identified in
+ <literal>HEAD</literal> as the path
+ <filename>frabnaggilywort/IDEA</filename> looked in revision
+ 1.</para>
+
+ <screen>
+$ svn cat -r 1 frabnaggilywort/IDEA at HEAD
+The idea behind this project is to come up with a piece of software
+that can frab a naggily wort. Frabbing naggily worts is tricky
+business, and doing it incorrectly can have serious ramifications, so
+we need to employ over-the-top input validation and data verification
+mechanisms.
+</screen>
+
+ <para>And the peg and operative revisions need not be so trivial,
+ either. For example, say <filename>frabnaggilywort</filename>
+ had been deleted from <literal>HEAD</literal>, but we know it
+ existed in revision 20, and we want to see the diffs for its
+ <filename>IDEA</filename> file between revisions 4 and 10. We
+ can use the peg revision 20 in conjunction with the URL that
+ would have held Frabnaggilywort's <filename>IDEA</filename> file
+ in revision 20, and then use 4 and 10 as our operative revision
+ range.</para>
+
+ <screen>
+$ svn diff -r 4:10 http://svn.red-bean.com/projects/frabnaggilywort/IDEA@20
+Index: frabnaggilywort/IDEA
+===================================================================
+--- frabnaggilywort/IDEA (revision 4)
++++ frabnaggilywort/IDEA (revision 10)
+@@ -1,5 +1,5 @@
+-The idea behind this project is to come up with a piece of software
+-that can frab a naggily wort. Frabbing naggily worts is tricky
+-business, and doing it incorrectly can have serious ramifications, so
+-we need to employ over-the-top input validation and data verification
+-mechanisms.
++The idea behind this project is to come up with a piece of
++client-server software that can remotely frab a naggily wort.
++Frabbing naggily worts is tricky business, and doing it incorrectly
++can have serious ramifications, so we need to employ over-the-top
++input validation and data verification mechanisms.
+</screen>
+
+ <para>Fortunately, most folks aren't faced with such complex
+ situations. But when you are, remember that peg revisions are
+ that extra hint Subversion needs to clear up ambiguity.</para>
+
+ </sect1>
+
<!-- ================================================================= -->
<!-- ================================================================= -->
@@ -92,18 +380,14 @@
<!-- @ENGLISH {{{
<title>Properties</title>
- <para>### TODO: This section needs love. It needs to not devolve
- into a property-by-property reference keyed on property names,
- but should instead remain high-level and functionally-keyed.
- Let the Reference be the by-propname lookup. ###</para>
-
<para>We've already covered in detail how Subversion stores and
retrieves various versions of files and directories in its
repository. Whole chapters have been devoted to this most
fundamental piece of functionality provided by the tool. And
if the versioning support stopped there, Subversion would still
- be complete from a version control perspective. But it
- doesn't stop there.</para>
+ be complete from a version control perspective.</para>
+
+ <para>But it doesn't stop there.</para>
<para>In addition to versioning your directories and files,
Subversion provides interfaces for adding, modifying, and
@@ -117,9 +401,10 @@
human-readable text. And the best part about these properties
is that they, too, are versioned, just like the textual contents
of your files. You can modify, commit, and revert property
- changes as easily as committing textual changes. And you
- receive other people's property changes as you update your
- working copy.</para>
+ changes as easily as you can file content changes. And the
+ sending and receiving of property changes occurs as part of your
+ typical commit and update operations—you don't have to
+ change your basic processes to accomodate them.</para>
@ENGLISH }}} -->
<title>Свойства</title>
@@ -128,8 +413,9 @@
посвящены этой самой фундаментальной части функциональных
возможностей этого инструмента. И если поддержка версионирования
этим ограничится, Subversion все равно останется полноценным
- инструментом с точки зрения управления версиями. Однако
- версионирование этим не ограничивается.</para>
+ инструментом с точки зрения управления версиями.</para>
+
+ <para>Однако версионирование этим не ограничивается.</para>
<para>Дополнительно к версионированнию директорий и файлов,
Subversion предоставляет для каждой версионированной директории
@@ -144,33 +430,45 @@
И лучшим из всего является то, что они тоже версионированы
также как и текстовое содержимое файлов. Можно также просто как и
для текстовых изменений изменять, фиксировать и отменять изменения
- свойств. При обновлении рабочей копии также получаются
- и изменения свойств.</para>
-
- <sidebar>
- <!-- @ENGLISH {{{
- <title>Other Properties in Subversion</title>
+ свойств. Отправка и получение редактирований свойств происходит точно
+ так же как и обычные фиксации и обновления — для этого нет
+ необходимости менять обычный порядок действий.</para>
- <para>Properties show up elsewhere in Subversion, too. Just as
- files and directories may have arbitrary property names and
- values attached to them, each revision as a whole may have
- arbitrary properties attached to it. The same constraints
- apply—human-readable, text names and anything-you-want,
- binary values—except that revision properties are not
- versioned. See <xref linkend="svn.reposadmin.basics.revprops" /> for more
- information on these unversioned properties.</para>
+ <!-- @ENGLISH {{{
+ <para>Properties show up elsewhere in Subversion, too. Just as
+ files and directories may have arbitrary property names and
+ values attached to them, each revision as a whole may have
+ arbitrary properties attached to it. The same constraints
+ apply—human-readable names and anything-you-want binary
+ values. The main difference is that revision properties are not
+ versioned. In other words, if you change the value of, or
+ delete, a revision property, there's no way within the scope of
+ Subversion's functionality to recover the previous value.</para>
@ENGLISH }}} -->
- <title>Еще один тип свойств в Subversion</title>
-
- <para>Подобные приведенным выше, свойства используются и Subversion.
- Так же как и произвольные имена свойств и соответствующие им значения,
- имеются у файлов и директорий, каждая правка может иметь
- произвольные свойства, присоединенные к ней. С теми же исключениями
- — читаемое, текстовое имя и любое бинарное значение —
- исключая версионирование свойств правок. Подробнее о таких
- неверсионированных свойствах см. <xref
- linkend="svn.reposadmin.basics.revprops" />.</para>
- </sidebar>
+ <para>Подобные приведенным выше, свойства используются и Subversion.
+ Так же как и произвольные имена свойств и соответствующие им значения,
+ имеются у файлов и директорий, каждая правка может иметь
+ произвольные свойства, присоединенные к ней. С теми же исключениями
+ — читаемое имя и любое бинарное значение. Главное отличие в том,
+ что свойства правок не версионируются. Другими словами, если изменить
+ значение свойства правки или удалить такое свойство, у Subversion нет
+ возможностей для востановления предыдущего значения.</para>
+
+ <para>Subversion has no particular policy regarding the use of
+ properties. It asks only that you not use property names that
+ begin with the prefix <literal>svn:</literal>. That's the
+ namespace that it sets aside for its own use. And Subversion
+ does, in fact, use properties, both the versioned and
+ unversioned variety. Certain versioned properties have special
+ meaning or effects when found on files and directories, or house
+ a particular bit of information about the revisions on which
+ they are found. Certain revision properties are automatically
+ attached to revisions by Subversion's commit process, and carry
+ information about the revision. Most of these properties are
+ mentioned elsewhere in this or other chapters as part of the
+ more general topics to which they are related. For an
+ exhaustive list of Subversion's pre-defined properties, see
+ <xref linkend="svn.ref.svnprops"/>.</para>
<!-- @ENGLISH {{{
<para>In this section, we will examine the utility—both to
@@ -192,83 +490,78 @@
<sect2 id="svn.advanced.props.why">
<!-- @ENGLISH {{{
<title>Why Properties?</title>
+ @ENGLISH }}} -->
+ <title>Зачем нужны свойства?</title>
- <para>Properties can be very useful additions to your working
- copy. In fact, Subversion itself uses properties to house
- special information, and as a way to denote that certain
- special processing might be needed. Likewise, you can use
- properties for your own purposes. Of course, anything you can
- do with properties you could also do using regular versioned
- files, but consider the following example of Subversion
- property use.</para>
-
+ <para>Just as Subversion uses properties to store extra
+ information about the files, directories, and revisions that
+ it contains, you might also find properties to be of similar
+ use. Some part of the processes around Subversion's usage
+ to which you adhere, or maybe some additional tooling around
+ Subversion that you use, might find utility in having a place
+ close to your versioned data to hang custom metadata about
+ that data.</para>
+
+ <!-- @ENGLISH {{{
<para>Say you wish to design a website that houses many digital
photos, and displays them with captions and a datestamp. Now,
your set of photos is constantly changing, so you'd like to
have as much of this site automated as possible. These photos
can be quite large, so as is common with sites of this nature,
you want to provide smaller thumbnail images to your site
- visitors. You can do this with traditional files. That is,
- you can have your <filename>image123.jpg</filename> and an
+ visitors.</para>
+
+ <para>Now, you can get this functionality using traditional
+ files. That is, you can have your
+ <filename>image123.jpg</filename> and an
<filename>image123-thumbnail.jpg</filename> side-by-side in a
directory. Or if you want to keep the filenames the same, you
might have your thumbnails in a different directory, like
<filename>thumbnails/image123.jpg</filename>. You can also
store your captions and datestamps in a similar fashion, again
- separated from the original image file. Soon, your tree of
- files is a mess, and grows in multiples with each new photo
- added to the site.</para>
+ separated from the original image file. But the problem here
+ is that your collection of files grows in multiples with each
+ new photo added to the site.</para>
@ENGLISH }}} -->
- <title>Зачем нужны свойства?</title>
-
- <para>Свойства могут быть очень полезной добавкой к рабочей копии.
- Фактически, сама Subversion использует свойства для хранения
- служебной информации и определения того, какие действия необходимо
- выполнить. Подобным образом и вы можете использовать свойства для
- своих целей. Конечно, все для чего можно использовать свойства
- можно делать, используя обычные версионированные файлы, однако
- обратите внимание на приведенный ниже пример использования
- Subversion-свойств.</para>
-
<para>Скажем, вы хотите разработать веб-сайт, содержащий много
цифровых фотографий и показывающий их с подписью и датой.
Набор этих фотографий постоянно изменяется и вы захотите
по возможности максимально автоматизировать этот сайт. Фотографии
могут быть большого размера и как обычно делают на таких
сайтах, для своих посетителей вам будет необходимо показывать
- миниатюры изображений. Сделать это вы можете с помощью обычных
+ миниатюры изображений.</para>
+
+ <para>Сделать это вы можете с помощью обычных
файлов. То есть рядом, в директории, вы можете иметь файлы
<filename>image123.jpg</filename> и
- <filename>image123-thumbnail.jpg</filename>. Подобным образом,
- отдельно от графического файла, можно хранить и дату. В результате
- ваше дерево файлов будет захламлено и будет многократно увеличиваться
- при каждом добавлении на сайт фотографии.</para>
+ <filename>image123-thumbnail.jpg</filename>. Либо если вам необходимо
+ сохранить то-же имя файла, миниатюры должны будут находиться в
+ отдельной директории, например, так
+ <filename>thumbnails/image123.jpg</filename>. Подобным-же образом,
+ отдельно от основного графического файла, можно хранить описание и
+ дату. Проблема здесь в том, что дерево файлов будет многократно
+ увеличиваться при каждом добавлении на сайт фотографии.</para>
<!-- @ENGLISH {{{
- <para>Now consider the same setup using Subversion's file
- properties. Imagine having a single image file,
- <filename>image123.jpg</filename>, and then properties set on
- that file named <literal>caption</literal>,
+ <para>Now consider the same website deployed in a way that makes
+ use of Subversion's file properties. Imagine having a single
+ image file, <filename>image123.jpg</filename>, and then
+ properties set on that file named <literal>caption</literal>,
<literal>datestamp</literal>, and even
<literal>thumbnail</literal>. Now your working copy directory
- looks much more manageable—in fact, it looks like there
- are nothing but image files in it. But your automation
- scripts know better. They know that they can use
- <command>svn</command> (or better yet, they can use the
- Subversion language bindings—see <xref
- linkend="svn.developer.usingapi.otherlangs" />) to dig out the extra
- information that your site needs to display without having to
- read an index file or play path manipulation games.</para>
-
- <para>How (and if) you use Subversion properties is up to you.
- As we mentioned, Subversion has it own uses for properties,
- which we'll discuss a little later in this chapter. But
- first, let's discuss how to manipulate properties using the
- <command>svn</command> program.</para>
+ looks much more manageable—in fact, it looks to the
+ casual browser like there are nothing but image files in it.
+ But your automation scripts know better. They know that they
+ can use <command>svn</command> (or better yet, they can use
+ the Subversion language bindings—see <xref
+ linkend="svn.developer.usingapi.otherlangs" />) to dig out the
+ extra information that your site needs to display without
+ having to read an index file or play path manipulation
+ games.</para>
@ENGLISH }}} -->
- <para>Представим эту же ситуацию при использовании Subversion-свойств
- файлов. Допустим, имеется файл <filename>image123.jpg</filename>
- и у этого файла установлено свойство
+ <para>Представим эту же ситуацию с веб сайтом, но при использовании
+ Subversion-свойств файлов. Допустим, имеется файл
+ <filename>image123.jpg</filename> и у этого файла установлено свойство
<literal>caption</literal>, <literal>datestamp</literal> и даже
<literal>thumbnail</literal>. В этом случае рабочая копия выглядит
гораздо более управляемо — фактически она будет выглядеть
@@ -281,11 +574,63 @@
не занимаясь чтением индексного файла или играми с путями
файлов.</para>
- <para>Как (и для чего) использовать Subversion-свойства вы решаете
- самостоятельно. Как уже говорилось, Subversion имеет свои применения
- свойств, которые мы рассмотрим в этой главе немного позже. А с начала
- давйте поговорим как работать со свойствами используя программу
- <command>svn</command>.</para>
+ <para>Custom revision properties are also frequently used. One
+ common such use is a property whose value contains an issue
+ tracker ID with which the revision is associated, perhaps
+ because the change made in that revision fixes a bug filed in
+ the tracker issue with that ID. Other uses include hanging
+ more friendly names on the revision—it might be hard to
+ remember that revision 1935 was a fully tested revision. But
+ if there's, say, a <literal>test-results</literal> property on
+ that revision with a value <literal>all passing</literal>,
+ that's meaningful information to have.</para>
+
+ <sidebar>
+ <title>Searchability (or, Why <emphasis>Not</emphasis>
+ Properties)</title>
+
+ <para>For all their utility, Subversion properties—or,
+ more accurately, the available interfaces to them—have
+ a major shortcoming which diminishes their practicality.
+ While it is a simple matter to set a custom property,
+ <emphasis>finding</emphasis> that property later is whole
+ different ball of wax.</para>
+
+ <para>Trying to locate a custom revision property generally
+ involves performing a linear walk across all the revisions
+ of the repository, asking of each revision, "Do you have the
+ property I'm looking for?" Trying to find a custom
+ versioned property is painful, too, and often involves a
+ recursive <command>svn propget</command> across an entire
+ working copy. In your situation, that might not be as bad
+ as a linear walk across all revisions. But it certainly
+ leaves much to be desired in terms of both performance and
+ likelihood of success, especially if the scope of your
+ search would require a working copy from the root of your
+ repository.</para>
+
+ <para>For this reason, you might choose—especially in
+ the revision property use-case—to simply add your
+ metadata to the revision's log message, using some
+ policy-driven (and perhaps programmatically-enforced)
+ formatting that is designed to be quickly parsed from the
+ output of <command>svn log</command>. It is quite common to
+ see in Subversion log messages the likes of:</para>
+
+ <programlisting>
+Issue(s): IZ2376, IZ1919
+Reviewed by: sally
+
+This fixes a nasty segfault in the wort frabbing process
+…
+</programlisting>
+
+ <para>But here again lies some misfortune. Subversion doesn't
+ yet provide a log message templating mechanism, which would
+ go a long way toward helping users be consistent with the
+ formatting of their log-embedded revision metadata.</para>
+
+ </sidebar>
</sect2>
@@ -367,18 +712,18 @@
<command>svn</command> program supplies the
<command>propedit</command> command. This command uses the
configured editor program (see <xref
- linkend="svn.advanced.confarea.opts.config" />) to add or modify properties.
- When you run the command, <command>svn</command> invokes your
- editor program on a temporary file that contains the current
- value of the property (or which is empty, if you are adding a
- new property). Then, you just modify that value in your
- editor program until it represents the new value you wish to
- store for the property, save the temporary file, and then exit
- the editor program. If Subversion detects that you've
- actually changed the existing value of the property, it will
- accept that as the new property value. If you exit your
- editor without making any changes, no property modification
- will occur.</para>
+ linkend="svn.advanced.confarea.opts.config" />) to add or
+ modify properties. When you run the command,
+ <command>svn</command> invokes your editor program on a
+ temporary file that contains the current value of the property
+ (or which is empty, if you are adding a new property). Then,
+ you just modify that value in your editor program until it
+ represents the new value you wish to store for the property,
+ save the temporary file, and then exit the editor program. If
+ Subversion detects that you've actually changed the existing
+ value of the property, it will accept that as the new property
+ value. If you exit your editor without making any changes, no
+ property modification will occur.</para>
@ENGLISH }}} -->
<para>Дополнительно к команде <command>propset</command>,
<command>svn</command> имеет команду <command>propedit</command>.
@@ -512,7 +857,7 @@
<!-- @ENGLISH {{{
<para>You need to use the <command>propdel</command> command to
delete properties altogether. The syntax is similar to the
- other property commands:</para>
+ преимущестпреимуществ:</para>
@ENGLISH }}} -->
<para>Для полного удаления свойств необходимо использовать
команду <command>propdel</command>. Ее синтаксис такой же
@@ -528,6 +873,102 @@
</screen>
<!-- @ENGLISH {{{
+ <para>Remember those unversioned revision properties? You can
+ modify those, too, using the same <command>svn</command>
+ subcommands that we just described. Simply add the
+ <option>-ﳢ-revprop</option> command-line parameter, and specify
+ the revision whose property you wish to modify. Since
+ revisions are global, you don't need to specify a target path
+ to these property-related commands so long as you are
+ positioned in a working copy of the repository whose
+ revision property you wish to modify. Otherwise, you can
+ simply provide the URL of any path in the repository of
+ interest (including the repository's root URL). For example,
+ you might want to replace the commit log message of an
+ existing revision.
+ <footnote>
+ <para>Fixing spelling errors, grammatical gotchas, and
+ <quote>just-plain-wrongness</quote> in commit log
+ messages is perhaps the most common use case for the
+ <option>-ﳢ-revprop</option> option.</para>
+ </footnote>
+ If your current working directory is part of a working copy of
+ your repository, you can simply run the
+ <command>svn propset</command> command with no target path:</para>
+ @ENGLISH }}} -->
+ <para>Помните, мы говорили о неверсионированных свойствах
+ правок? Их то же можно менять с помощью <command>svn</command>.
+ Просто добавьте параметр командной строки <option>--revprop</option>
+ и укажите правку, чье свойство вы хотите изменить. Учитывая
+ глобальность правок, в этом случае не нужно указывать путь, так как
+ вы находитесь в рабочей копии хранилища, в котором вы хотите
+ изменить свойство правки. В противном случае, нужно просто указать
+ интересующий вас в хранилище URL (в том числе, это может быть и
+ корневой URL хранилища). Например, может понадобиться заменить
+ лог-сообщение фиксации в существующей правке. <footnote>
+ <para>Исправление в лог сообщениях орфографических, грамматических
+ ошибок, <quote>просто ошибочных</quote> записей, наверно,
+ самые распространенные случаи использования параметра
+ <option>--revprop</option>.</para></footnote>Если текущая рабочая
+ директория является частью рабочей копии хранилища, можно просто
+ выполнить команду <command>svn propset</command>, не указывая целевой
+ путь:</para>
+
+ <screen>
+$ svn propset svn:log '* button.c: Fix a compiler warning.' -r11 --revprop
+property 'svn:log' set on repository revision '11'
+$
+</screen>
+
+ <para>But even if you haven't checked out a working copy from
+ that repository, you can still affect the property change by
+ providing the repository's root URL:</para>
+
+ <screen>
+$ svn propset svn:log '* button.c: Fix a compiler warning.' -r11 --revprop \
+ http://svn.example.com/repos/project
+property 'svn:log' set on repository revision '11'
+$
+</screen>
+
+ <!-- @ENGLISH {{{
+ <para>Note that the ability to modify these unversioned
+ properties must be explicitly added by the repository
+ administrator (see <xref linkend="svn.reposadmin.create.hooks" />).
+ Since the properties aren't versioned, you run the risk of
+ losing information if you aren't careful with your edits.
+ The repository administrator can setup methods to protect
+ against this loss, and by default, modification of
+ unversioned properties is disabled.</para>
+ @ENGLISH }}} -->
+ <para>Обратите внимание на то, что изменение этих
+ неверсионированных свойств должно быть явно разрешено
+ администратором (см. <xref
+ linkend="svn.reposadmin.create.hooks" />). Учитывая то, что
+ свойства не версионируются, при не аккуратном редактировании,
+ вы рискуете потерять информацию. Для исключения потери информации,
+ администратор хранилища может принять меры предосторожности и
+ по умолчанию, изменение неверсионированных свойств
+ запрещено.</para>
+
+ <tip>
+ <para>Users should, where possible, use <command>svn
+ propedit</command> instead of <command>svn
+ propset</command>. While the end result of the commands is
+ identical, the former will allow them to see the current
+ value of the property they are about to change, which helps
+ them to verify that they are, in fact, making the change
+ they think they are making. This is especially true when
+ modifying unversioned revision properties.</para>
+ </tip>
+
+ </sect2>
+
+ <!-- =============================================================== -->
+ <sect2 id="svn.advanced.props.workflow">
+ <title>Properties and the Subversion Workflow</title>
+
+ <!-- @ENGLISH {{{
<para>Now that you are familiar with all of the
property-related <command>svn</command> subcommands, let's see
how property modifications affect the usual Subversion
@@ -546,69 +987,6 @@
— в случае конфликтных ситуаций — чужих изменений
с вашими собственными.</para>
- <sidebar>
- <!-- @ENGLISH {{{
- <title>Modifying Revision Properties</title>
-
- <para>Remember those unversioned revision properties? You can
- modify those, too, with the <command>svn</command> program.
- Simply add the <option>-ﳢ-revprop</option> command-line
- parameter, and specify the revision whose property you wish
- to modify. Since revisions are global, you don't need to
- specify a path in this case as long as you are positioned in
- the working copy of the repository whose revision property
- you wish to modify. For example, you might want to replace
- the commit log message of an existing revision.
- <footnote>
- <para>Fixing spelling errors, grammatical gotchas, and
- <quote>just-plain-wrongness</quote> in commit log
- messages is perhaps the most common use case for the
- <option>-ﳢ-revprop</option> option.</para>
- </footnote></para>
- @ENGLISH }}} -->
- <title>Редактирование свойств правок</title>
-
- <para>Помните, мы говорили о неверсионированных свойствах
- правок? Их то же можно менять с помощью <command>svn</command>.
- Просто добавьте параметр командной строки <option>--revprop</option>
- и укажите правку, чье свойство вы хотите изменить. Учитывая
- глобальность правок, в этом случае не нужно указывать путь, так как
- вы находитесь в рабочей копии хранилища, в котором вы хотите
- изменить свойство правки. Например, может понадобиться заменить
- лог-сообщение фиксации в существующей правке. <footnote>
- <para>Исправление в лог сообщениях орфографических, грамматических
- ошибок, <quote>просто ошибочных</quote> записей, наверно,
- самые распространенные случаи использования параметра
- <option>--revprop</option>.</para></footnote></para>
-
- <screen>
-$ svn propset svn:log '* button.c: Fix a compiler warning.' -r11 --revprop
-property 'svn:log' set on repository revision '11'
-$
-</screen>
-
- <!-- @ENGLISH {{{
- <para>Note that the ability to modify these unversioned
- properties must be explicitly added by the repository
- administrator (see <xref linkend="svn.reposadmin.create.hooks" />).
- Since the properties aren't versioned, you run the risk of
- losing information if you aren't careful with your edits.
- The repository administrator can setup methods to protect
- against this loss, and by default, modification of
- unversioned properties is disabled.</para>
- @ENGLISH }}} -->
- <para>Обратите внимание на то, что изменение этих
- неверсионированных свойств должно быть явно разрешено
- администратором (см. <xref
- linkend="svn.reposadmin.create.hooks" />). Учитывая то, что
- свойства не версионируются, при не аккуратном редактировании,
- вы рискуете потерять информацию. Для исключения потери информации,
- администратор хранилища может принять меры предосторожности и
- по умолчанию, изменение неверсионированных свойств
- запрещено.</para>
-
- </sidebar>
-
<!-- @ENGLISH {{{
<para>And as with file contents, your property changes are local
modifications, only made permanent when you commit them to the
@@ -773,272 +1151,506 @@
</sect2>
<!-- =============================================================== -->
- <sect2 id="svn.advanced.props.special">
+ <sect2 id="svn.advanced.props.auto">
+ <title>Automatic Property Setting</title>
- <!-- @ENGLISH {{{
- <title>Special Properties</title>
+ <para>Properties are a powerful feature of Subversion, acting as
+ key components of many Subversion features discussed elsewhere
+ in this and other chapters—textual diff and merge
+ support, keyword substitution, newline translation, etc. But
+ to get the full benefit of properties, they must be set on the
+ right files and directories. Unfortunately, that can be a
+ step easily forgotten in the routine of things, especially
+ since failing to set a property doesn't usually result in an
+ obvious error condition (at least compared to, say, failing to
+ add a file to version control). To help your properties get
+ applied to the places that need them, Subversion provides a
+ couple of simple but useful features.</para>
- <para>Subversion has no particular policy regarding
- properties—you can use them for any purpose. Subversion
- asks only that you not use property names that begin with the
- prefix <literal>svn:</literal>. That's the namespace that it
- sets aside for its own use. In fact, Subversion defines
- certain properties that have magical effects on the files and
- directories to which they are attached. In this section,
- we'll untangle the mystery, and describe how these special
- properties make your life just a little easier.</para>
- @ENGLISH }}} -->
- <title>Специальные свойства</title>
+ <para>Whenever you introduce a file to version control using the
+ <command>svn add</command> or <command>svn import</command>
+ commands, Subversion tries to assist by setting some common
+ file properties automatically. First, on operating systems
+ whose filesystems support an execute permission bit,
+ Subversion will automatically set the
+ <literal>svn:executable</literal> property on newly added or
+ imported files whose execute bit is enabled. (See <xref
+ linkend="svn.advanced.props.special.executable" /> for more
+ about this property.) Secondly, it runs a very basic
+ heuristic to determine if that file contains human-readable
+ content. If not, Subversion will automatically set the
+ <literal>svn:mime-type</literal> property on that file to
+ <literal>application/octet-stream</literal> (the generic
+ <quote>this is a collection of bytes</quote> MIME type). Of
+ course, if Subversion guesses incorrectly, or if you wish to
+ set the <literal>svn:mime-type</literal> property to something
+ more precise—perhaps <literal>image/png</literal> or
+ <literal>application/x-shockwave-flash</literal>—you can
+ always remove or edit that property. (For more on
+ Subversion's use of MIME types, see <xref
+ linkend="svn.advanced.props.special.mime-type" />.)</para>
+
+ <para>Subversion also provides, via its runtime configuration
+ system, a more flexible automatic property setting feature
+ which allows you to create mappings of filename patterns to
+ property names and values. Once again, these mappings affect
+ adds and imports, and not only can override the default MIME
+ type decision made by Subversion during those operations, but
+ can also set additional Subversion or custom properties, too.
+ For example, you might create a mapping that says that any
+ time you add JPEG files—ones that match the pattern
+ <literal>*.jpg</literal>—Subversion should automatically
+ set the <literal>svn:mime-type</literal> property on those
+ files to <literal>image/jpeg</literal>. Or perhaps any files
+ that match <literal>*.cpp</literal> should have
+ <literal>svn:eol-style</literal> set to
+ <literal>native</literal>, and <literal>svn:keywords</literal>
+ set to <literal>Id</literal>. Auto-prop support is perhaps
+ the handiest property related tool in the Subversion toolbox.
+ See <xref linkend="svn.advanced.confarea.opts.config"/> for
+ more about configuring that support.</para>
+
+ </sect2>
+ </sect1>
+
+ <!-- ================================================================= -->
+ <!-- ================================================================= -->
+ <!-- ================================================================= -->
+ <sect1 id="svn.advanced.props.file-portability">
+ <title>File Portability</title>
- <para>У Subversion нет каких то отдельных правил для свойств
- — использовать их можно как угодно. Единственно
- что Subversion требует от вас не использовать в названиях
- свойств префикс <literal>svn:</literal>. Потому, что это
- пространство имен для ее личного использования. Subversion
- выделяет несколько свойств, имеющих особый магический эффект
- для файлов и директорий, для которых они установлены.
- В этом разделе мы раскроем тайну и расскажем, как эти
- специальные свойства делают жизнь немного проще.</para>
+ <para>Fortunately for Subversion users who routinely find
+ themselves on different computers with different operating
+ systems, Subversion's command-line programs almost universally
+ behave identically across all those systems. If you know how to
+ wield <command>svn</command> on one platform, you know how to
+ wield it everywhere.</para>
+
+ <para>However, the same is not always true of other general classes
+ of software, or of the actual files you keep in Subversion. For
+ example, on a Windows machine, the definition of a <quote>text
+ file</quote> would be similar to that used on a Linux box, but
+ with a key difference—the character sequences used to mark
+ the ends of the lines of those files. There are other
+ differences, too. Unix platforms have (and Subversion supports)
+ symbolic links; Windows does not. Unix platforms use filesystem
+ permission to determine executability; Windows uses filename
+ extensions.</para>
+
+ <para>Because Subversion is in no position to unite the whole
+ world in common definitions and implementations of all of these
+ things, the best it can do is to try to help make your life
+ simpler when you need to work with your versioned files and
+ directories on multiple computers and operating systems. This
+ section describes some of the ways Subversion does this.</para>
- <sect3 id="svn.advanced.props.special.executable">
- <title><literal>svn:executable</literal></title>
+ <!-- =============================================================== -->
+ <sect2 id="svn.advanced.props.special.mime-type">
+ <title>File Content Type</title>
- <!-- @ENGLISH {{{
- <para>The <literal>svn:executable</literal> property is used
- to control a versioned file's filesystem-level execute
- permission bit in a semi-automated way. This property has
- no defined values—its mere presence indicates a desire
- that the execute permission bit be kept enabled by Subversion.
- Removing this property will restore full control of the
- execute bit back to the operating system.</para>
-
- <para>On many operating systems, the ability to execute a file
- as a command is governed by the presence of an execute
- permission bit. This bit usually defaults to being
- disabled, and must be explicitly enabled by the user for
- each file that needs it. In a working copy, new files are
- being created all the time as new versions of existing files
- are received during an update. This means that you might
- enable the execute bit on a file, then update your working
- copy, and if that file was changed as part of the update,
- its execute bit might get disabled. So, Subversion provides
- the <literal>svn:executable</literal> property as a way to
- keep the execute bit enabled.</para>
+ <para>Software programs on most modern operating systems make
+ assumptions about the type and format of the contents of a
+ file by the file's name, specifically its file extension. For
+ example, files whose names end in <filename>.txt</filename>
+ are generally assumed to be human-readable, able to be
+ understood by simple perusal rather than requiring complex
+ processing to decipher. Files whose names end in
+ <filename>.png</filename>, on the other hand, are assumed to
+ be of the Portable Network Graphics type—not
+ human-readable at all, and sensible only when interpreted by
+ software which understands the PNG format and can render the
+ information in that format as a raster image.</para>
+
+ <para>Unfortunately, some of those extensions have changed
+ meanings over time. When personal computers first appeared, a
+ file named <filename>README.DOC</filename> would have almost
+ certainly been a plaintext file, just like today's
+ <filename>.txt</filename> files. But by the mid-1990's,
+ you could almost bet that a file of that name would not be a
+ plaintext file at all, but instead a Microsoft Word document
+ with a proprietary, non-human-readable format. But this
+ change didn't occur overnight—there was certainly a
+ period of confusion for computer users over what exactly they
+ had in hand when they saw a <filename>.DOC</filename> file.
+ <footnote>
+ <para>You think that was rough? During that same era,
+ WordPerfect also used <filename>.DOC</filename> for their
+ proprietary file format's preferred extension!</para>
+ </footnote>
+ </para>
+
+ <para>The popularity of computer networking cast still more
+ doubt on the mapping between a file's name and its content.
+ With information being served across networks and generated
+ dynamically by server-side scripts, there was often no real
+ file <foreignphrase>per se</foreignphrase> to speak of, and
+ therefore no file name. Web servers, for example, needed some
+ other way to tell browsers what they were downloading so the
+ browser could do something intelligent with that information,
+ whether that was to display the data using a program
+ registered to handle that data type, or to prompt the user for
+ where on the client machine to store the downloaded
+ data.</para>
+
+ <para>Eventually, a standard emerged for, among other things,
+ describing the contents of a data stream. In 1996, RFC2045
+ was published, the first of five RFCs describing Multipurpose
+ Internet Mail Extensions (MIME). In it, this RFC describes
+ the concept of media types and subtypes, and recommends a
+ syntax for the representation of those types. Today, MIME
+ media types—or, MIME types— are used almost
+ universally across e-mail applications, Web servers, and other
+ software as the <foreignphrase>de facto</foreignphrase>
+ mechanism for clearing up the file content confusion.</para>
+
+ <para>Subversion joins the ranks of applications which recognize
+ and make use of MIME types. Besides being a general-purpose
+ storage location for a file's content type, the value of the
+ <literal>svn:mime-type</literal> file property determines some
+ behavioral characteristics of Subversion itself.</para>
+
+ <para>For example, one of the benefits that Subversion typically
+ provides is contextual, line-based merging of changes received
+ from the server during an update into your working file. But
+ for files containing non-textual data, there is often no
+ concept of a <quote>line</quote>. So, for versioned files
+ whose <literal>svn:mime-type</literal> property is set to a
+ non-textual MIME type (generally, something that doesn't begin
+ with <literal>text/</literal>, though there are exceptions),
+ Subversion does not attempt to perform contextual merges
+ during updates. Instead, any time you have locally modified a
+ binary working copy file that is also being updated, your file
+ is renamed with a <filename>.orig</filename> extension, and
+ then Subversion stores a new working copy file that contains
+ the changes received during the update, but not your own local
+ modifications, at the original filename. This behavior is
+ really for the protection of the user against failed attempts
+ at performing contextual merges on files that simply cannot be
+ contextually merged.</para>
+
+ <para>Also, if the <literal>svn:mime-type</literal> property is
+ set, then the Subversion Apache module will use its value to
+ populate the <literal>Content-type:</literal> HTTP header when
+ responding to GET requests. This gives your web browser a
+ crucial clue about how to display a file when using it to
+ peruse your Subversion repository's contents.</para>
+
+ </sect2>
+
+ <!-- =============================================================== -->
+ <sect2 id="svn.advanced.props.special.executable">
+ <title>File Executability</title>
+
+ <!-- @ENGLISH {{{
+ <para>On many operating systems, the ability to execute a file
+ as a command is governed by the presence of an execute
+ permission bit. This bit usually defaults to being disabled,
+ and must be explicitly enabled by the user for each file that
+ needs it. But it would be a monumental hassle to have to
+ remember exactly which files in freshly checked-out working
+ copy were supposed to have their executable bits toggled on,
+ and then to have to do that toggling. So, Subversion provides
+ the <literal>svn:executable</literal> property as a way to
+ specify that the executable bit for the file on which that
+ property is set should be enabled, and Subversion honors that
+ request when populating working copies with such files.</para>
@ENGLISH }}} -->
- <para>Свойство <literal>svn:executable</literal> для версионированного
- файла контролирует в полуавтоматическом режиме бит файловой
- системы, разрешающий исполнение. Это свойство не имеет определенного
- значения — просто его наличие говорит о необходимости для
- Subversion выставлять бит разрешения выполнения. Удаление этого
- свойства востанавливает полный контроль операционной системы над
- битом выполнения.</para>
-
- <para>На многих операционных системах возможность выполнения файла
- как команды определяется битом разрешения выполнения. Обычно по
- умолчанию этот бит не установлен и для файлов которым это
- необходимо, он должен быть явно установлен пользователем.
- Файлы в рабочей копии при обновлении создаются каждый раз
- заново если во время обновления получается новая версия.
- Это значит, что вы можете установить бит разрешения выполнения,
- а если при выполнении обновления обновился и этот файл,
- бит разрешения выполнения может оказаться опять сброшеным.
- Для таких случаев Subversion и предлагает использовать
- свойство <literal>svn:executable</literal>, как способ сохранения
- бита разрешения выполнения.</para>
+ <para>На многих операционных системах возможность выполнения файла
+ как команды определяется битом разрешения выполнения. Обычно по
+ умолчанию этот биm