[svnbook commit] r2813 - in trunk/src/ru: . book
dmitriy
noreply at red-bean.com
Fri Jun 29 13:24:49 CDT 2007
Author: dmitriy
Date: Fri Jun 29 13:24:49 2007
New Revision: 2813
Log:
* ru/book/ch-advanced-topics.xml
ru/book/ch-reference.xml
Merge r2608:2625
* ru/sync.py
Fix a typo
* ru/TRANSLATION-STATUS
Automatically update by sync.py
Modified:
trunk/src/ru/TRANSLATION-STATUS
trunk/src/ru/book/ (props changed)
trunk/src/ru/book/ch-advanced-topics.xml
trunk/src/ru/book/ch-reference.xml
trunk/src/ru/sync.py
Modified: trunk/src/ru/TRANSLATION-STATUS
==============================================================================
--- trunk/src/ru/TRANSLATION-STATUS (original)
+++ trunk/src/ru/TRANSLATION-STATUS Fri Jun 29 13:24:49 2007
@@ -38,7 +38,7 @@
Эти файлы переведены частично и работа над переводом продолжается,
или же в данный момент перевод этих файлов обновляется.
- * ch-advanced-topics.xml, 18%
+ * ch-advanced-topics.xml, 22%
* ch-branching-and-merging.xml, 82%
* ch-customizing-svn.xml, 64%
* ch-reference.xml, 22%
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 Fri Jun 29 13:24:49 2007
@@ -251,17 +251,17 @@
spaces.)</para>
<screen>
-$ svn checkout -r {2002-02-17}
+$ svn checkout -r {2006-02-17}
$ svn checkout -r {15:30}
$ svn checkout -r {15:30:00.200000}
-$ svn checkout -r {"2002-02-17 15:30"}
-$ svn checkout -r {"2002-02-17 15:30 +0230"}
-$ svn checkout -r {2002-02-17T15:30}
-$ svn checkout -r {2002-02-17T15:30Z}
-$ svn checkout -r {2002-02-17T15:30-04:00}
-$ svn checkout -r {20020217T1530}
-$ svn checkout -r {20020217T1530Z}
-$ svn checkout -r {20020217T1530-0500}
+$ svn checkout -r {"2006-02-17 15:30"}
+$ svn checkout -r {"2006-02-17 15:30 +0230"}
+$ svn checkout -r {2006-02-17T15:30}
+$ svn checkout -r {2006-02-17T15:30Z}
+$ svn checkout -r {2006-02-17T15:30-04:00}
+$ svn checkout -r {20060217T1530}
+$ svn checkout -r {20060217T1530Z}
+$ svn checkout -r {20060217T1530-0500}
…
</screen>
@@ -271,9 +271,9 @@
number:</para>
<screen>
-$ svn log --revision {2002-11-28}
+$ svn log -r {2006-11-28}
------------------------------------------------------------------------
-r12 | ira | 2002-11-27 12:31:51 -0600 (Wed, 27 Nov 2002) | 6 lines
+r12 | ira | 2006-11-27 12:31:51 -0600 (Mon, 27 Nov 2006) | 6 lines
…
</screen>
@@ -286,38 +286,38 @@
<!-- @ENGLISH {{{
<para>If you specify a single date as a revision without
specifying a time of day (for example
- <literal>2002-11-27</literal>), you may think that Subversion
+ <literal>2006-11-27</literal>), you may think that Subversion
should give you the last revision that took place on the
27th of November. Instead, you'll get back a revision from
the 26th, or even earlier. Remember that Subversion will
find the <emphasis>most recent revision of the
repository</emphasis> as of the date you give. If you give
a date without a timestamp, like
- <literal>2002-11-27</literal>, Subversion assumes a time of
+ <literal>2006-11-27</literal>, Subversion assumes a time of
00:00:00, so looking for the most recent revision won't
return anything on the day of the 27th.</para>
@ENGLISH }}} -->
<para>Указав при обращении к правке только дату, без указания
- времени (например, <literal>2002-11-27</literal>), возможно
+ времени (например, <literal>2006-11-27</literal>), возможно
вы подумаете, что Subversion выдаст вам последнюю правку за 27
ноября. А вместо этого можете получить правку за 26 число или
даже более раннюю. Помните, что Subversion будет искать
<emphasis>наиболее отвечающую</emphasis> указанной вами дате
правку хранилища. Если вы укажите дату без указания времени,
- например <literal>2002-11-27</literal>, Subversion примет за
+ например <literal>2006-11-27</literal>, Subversion примет за
временную метку 00:00:00 и таким образом поиск ближайшей к 27
числу ревизии не даст ничего относящегося к 27 ноября.</para>
<!-- @ENGLISH {{{
<para>If you want to include the 27th in your search, you can
- either specify the 27th with the time (<literal>{"2002-11-27
+ either specify the 27th with the time (<literal>{"2006-11-27
23:59"}</literal>), or just specify the next day
- (<literal>{2002-11-28}</literal>).</para>
+ (<literal>{2006-11-28}</literal>).</para>
@ENGLISH }}} -->
<para>Если вам необходимо найти именно 27 число, вы можете либо
- указать 27 число с временной меткой (<literal>{"2002-11-27
+ указать 27 число с временной меткой (<literal>{"2006-11-27
23:59"}</literal>) либо просто использовать в запросе следующий
- день (<literal>{2002-11-28}</literal>).</para>
+ день (<literal>{2006-11-28}</literal>).</para>
</sidebar>
@@ -329,9 +329,7 @@
найдет все правки между обеими датами включительно:</para>
<screen>
-$ svn log -r {2002-11-28}
-------------------------------------------------------------------------
-r12 | ira | 2002-11-27 12:31:51 -0600 (Wed, 27 Nov 2002) | 6 lines
+$ svn log -r {2006-11-20}:{2006-11-29}
…
</screen>
@@ -352,834 +350,524 @@
<!-- ================================================================= -->
<!-- ================================================================= -->
<!-- ================================================================= -->
- <sect1 id="svn.advanced.pegrevs">
- <title>Peg and Operative Revisions</title>
+ <sect1 id="svn.advanced.props">
+ <!-- @ENGLISH {{{
+ <title>Properties</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
- object might have many paths, and a given path might represent
- several entirely different versioned objects. And this
- introduces a certain level of complexity to your interactions
- with those paths and objects.</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.</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>But it doesn't stop there.</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>In addition to versioning your directories and files,
+ Subversion provides interfaces for adding, modifying, and
+ removing versioned metadata on each of your versioned
+ directories and files. We refer to this metadata as
+ <firstterm>properties</firstterm>, and they can be thought of as
+ two-column tables that map property names to arbitrary values
+ attached to each item in your working copy. Generally speaking,
+ the names and values of the properties can be whatever you want
+ them to be, with the constraint that the names must be
+ 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 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>
+ <para>Мы уже рассмотрели как Subversion сохраняет и получает
+ разные версии файлов и директорий из хранилища. Целые главы были
+ посвящены этой самой фундаментальной части функциональных
+ возможностей этого инструмента. И если поддержка версионирования
+ этим ограничится, Subversion все равно останется полноценным
+ инструментом с точки зрения управления версиями.</para>
+
+ <para>Однако версионирование этим не ограничивается.</para>
- <para>And thanks to moves, versioned object 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>Дополнительно к версионированнию директорий и файлов,
+ Subversion предоставляет для каждой версионированной директории
+ и файла интерфейс для добавления, изменения и удаления
+ версионированных метаданных. К этим метаданным мы обращаемся как
+ к <firstterm>свойствам</firstterm>, присоединенным к каждому
+ элементу рабочей копии, которые можно представить
+ в виде таблицы с двумя столбцами, которая сопоставляет
+ имена свойств соответствующим значениям. Вообще, имена
+ и значения свойств могут быть тем, чем вы хотите чтобы они были,
+ за исключением того, что имена должны быть читаемым текстом.
+ И лучшим из всего является то, что они тоже версионированы
+ также как и текстовое содержимое файлов. Можно также просто как и
+ для текстовых изменений изменять, фиксировать и отменять изменения
+ свойств. Отправка и получение измененных свойств происходит точно
+ так же как и обычные фиксации и обновления — для этого нет
+ необходимости менять обычный порядок действий.</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>
+ <!-- @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 }}} -->
+ <para>Подобные приведенным выше, свойства используются и Subversion.
+ Так же как и произвольные имена свойств и соответствующие им значения,
+ имеются у файлов и директорий, каждая правка может иметь
+ произвольные свойства, присоединенные к ней. С теми же исключениями
+ — читаемое имя и любое бинарное значение. Главное отличие в том,
+ что свойства правок не версионируются. Другими словами, если изменить
+ значение свойства правки или удалить такое свойство, у Subversion нет
+ возможностей для восстановления предыдущего значения.</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 object
- 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>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>
- <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>
+ <!-- @ENGLISH {{{
+ <para>In this section, we will examine the utility—both to
+ users of Subversion, and to Subversion itself—of property
+ support. You'll learn about the property-related
+ <command>svn</command> subcommands, and how property
+ modifications affect your normal Subversion workflow.
+ Hopefully, you'll be convinced that Subversion properties can
+ enhance your version control experience.</para>
+ @ENGLISH }}} -->
+ <para>В этом разделе мы рассмотрим полезность — как для
+ пользователя, так и для самой Subversion — поддержки
+ свойств. Вы узнаете о командах <command>svn</command>, относящихся к
+ свойствам и том как модификация свойств влияет на привычный рабочий
+ цикл. Надеемся, вы убедитесь в том, что свойства в Subversion
+ расширяют возможности контроля версий.</para>
- <sidebar>
- <title>The peg revision algorithm</title>
-
- <para>The Subversion command-line performs the peg revision
- algorithm 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>
+ <!-- =============================================================== -->
+ <sect2 id="svn.advanced.props.why">
+ <!-- @ENGLISH {{{
+ <title>Why Properties?</title>
+ @ENGLISH }}} -->
+ <title>Зачем нужны свойства?</title>
- <screen>
-$ svn <replaceable>command</replaceable> -r <replaceable>OPERATIVE-REV</replaceable> item@<replaceable>PEG-REV</replaceable>
-</screen>
-
- <para>The algorithm has three simple steps:</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>
- <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>
+ <!-- @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.</para>
- <listitem>
- <para>Trace the object's history backwards (through any
- possible renames) to its ancestor in the
- revision <replaceable>OPERATIVE-REV</replaceable>.</para>
- </listitem>
+ <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. But the problem here
+ is that your collection of files grows in multiples with each
+ new photo added to the site.</para>
+ @ENGLISH }}} -->
+ <para>Скажем, вы хотите разработать веб-сайт, содержащий много
+ цифровых фотографий и показывающий их с подписью и датой.
+ Набор этих фотографий постоянно изменяется и вы захотите
+ по возможности максимально автоматизировать этот сайт. Фотографии
+ могут быть большого размера и как обычно делают на таких
+ сайтах, для своих посетителей вам будет необходимо показывать
+ миниатюры изображений.</para>
- <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>
+ <para>Сделать это вы можете с помощью обычных
+ файлов. То есть рядом, в директории, вы можете иметь файлы
+ <filename>image123.jpg</filename> и
+ <filename>image123-thumbnail.jpg</filename>. Либо если вам необходимо
+ сохранить то-же имя файла, миниатюры должны будут находиться в
+ отдельной директории, например, так
+ <filename>thumbnails/image123.jpg</filename>. Подобным-же образом,
+ отдельно от основного графического файла, можно хранить описание и
+ дату. Проблема здесь в том, что дерево файлов будет многократно
+ увеличиваться при каждом добавлении на сайт фотографии.</para>
- </itemizedlist>
+ <!-- @ENGLISH {{{
+ <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 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> и у этого файла установлено свойство
+ <literal>caption</literal>, <literal>datestamp</literal> и даже
+ <literal>thumbnail</literal>. В этом случае рабочая копия выглядит
+ гораздо более управляемо — фактически она будет выглядеть
+ так, как будто она ничего кроме графических файлов не содержит.
+ Однако ваш скрипт автоматизации знает больше. Он знает, что может
+ воспользоваться <command>svn</command> (а еще лучше языковой обвязкой
+ Subversion — см. <xref
+ linkend="svn.developer.usingapi.otherlangs" />) для получения
+ дополнительной, необходимой для показа на сайте информации,
+ не занимаясь чтением индексного файла или играми с путями
+ файлов.</para>
- <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>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>
- <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>
+ <sidebar>
+ <title>Searchability (or, Why <emphasis>Not</emphasis>
+ Properties)</title>
- <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>
+ <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>
- <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>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>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>
+ <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>
- <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>
+ <programlisting>
+Issue(s): IZ2376, IZ1919
+Reviewed by: sally
- <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>
+This fixes a nasty segfault in the wort frabbing process
+…
+</programlisting>
- <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>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>
- <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>
+ </sidebar>
- <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>
+ </sect2>
- <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>
+ <!-- =============================================================== -->
+ <sect2 id="svn.advanced.props.manip">
+ <!-- @ENGLISH {{{
+ <title>Manipulating Properties</title>
- <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>
+ <para>The <command>svn</command> command affords a few ways to
+ add or modify file and directory properties. For properties
+ with short, human-readable values, perhaps the simplest way to
+ add a new property is to specify the property name and value
+ on the command-line of the <command>propset</command>
+ subcommand.</para>
+ @ENGLISH }}} -->
+ <title>Использование свойств</title>
- <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>Команда <command>svn</command> предоставляет несколько
+ способов добавления или изменения свойств файлов и директорий.
+ Свойства с короткими, читаемыми значениями, наверное проще всего
+ добавить указав имя и значение свойства в командной строке
+ подкоманды <command>propset</command>.</para>
- <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 propset copyright '(c) 2006 Red-Bean Software' calc/button.c
+property 'copyright' set on 'calc/button.c'
+$
+</screen>
- <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>
+ <!-- @ENGLISH {{{
+ <para>But we've been touting the flexibility that Subversion
+ offers for your property values. And if you are planning to
+ have a multi-line textual, or even binary, property value, you
+ probably do not want to supply that value on the command-line.
+ So the <command>propset</command> subcommand takes a
+ <option>-ﳢ-file</option> (<option>-F</option>) option for
+ specifying the name of
+ a file which contains the new property value.</para>
+ @ENGLISH }}} -->
+ <para>Однако мы уже знаем о гибкости, предлагаемой Subversion
+ для значений свойств. И если вам необходимо иметь многострочное
+ текстовое, или даже бинарное значение свойства, передавать
+ такое значение через командную строку не удобно. Для
+ таких случаев команда <command>propset</command> имеет
+ параметр <option>--file</option> (<option>-F</option>), указывающий
+ имя файла, содержащего новое значение свойства.</para>
- <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>
+ <screen>
+$ svn propset license -F /path/to/LICENSE calc/button.c
+property 'license' set on 'calc/button.c'
+$
+</screen>
- </sect1>
+ <!-- @ENGLISH {{{
+ <para>There are some restrictions on the names you can use for
+ properties. A property name must start with a letter, a colon
+ (<literal>:</literal>), or an underscore
+ (<literal>_</literal>); after that, you can also use digits,
+ hyphens (<literal>-</literal>), and periods
+ (<literal>.</literal>).
+ <footnote>
+ <para>If you're familiar with XML, this is pretty much the
+ ASCII subset of the syntax for XML "Name".</para>
+ </footnote>
+ </para>
+ @ENGLISH }}} -->
+ <para>Для имен свойств существует ряд ограничений. Имя свойства должно
+ начинаться с буквы, двоеточия (<literal>:</literal>) или подчеркивания
+ (<literal>_</literal>); дальше можно использовать цифры, тире
+ (<literal>-</literal>) и точки (<literal>.</literal>).
+ <footnote>
+ <para>Если вы знакомы с XML, то синтаксис XML "Name" использует
+ практически тот же ASCII набор.</para>
+ </footnote>
+ </para>
+ <!-- @ENGLISH {{{
+ <para>In addition to the <command>propset</command> command, the
+ <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>
+ @ENGLISH }}} -->
+ <para>Дополнительно к команде <command>propset</command>,
+ <command>svn</command> имеет команду <command>propedit</command>.
+ Эта команда использует для добавления или изменения свойств указанную
+ программу-редактор (см. <xref
+ linkend="svn.advanced.confarea.opts.config" />). При выполнении
+ команды, <command>svn</command> вызывает редактор с временным файлом,
+ содержащим текущее значение свойства (или с пустым файлом, если
+ добавляется новое свойство). Затем вы просто меняете в редакторе
+ значение, пока оно не станет таким, каким бы вы хотели его видеть,
+ сохраняете временный файл и выходите из редактора. Если Subversion
+ обнаружит, что вы действительно изменили существующие значение
+ свойства, будет установлено новое значение. Если вы вышли из
+ редактора не внеся изменений, модификации свойства не
+ произойдет.</para>
- <!-- ================================================================= -->
- <!-- ================================================================= -->
- <!-- ================================================================= -->
- <sect1 id="svn.advanced.props">
- <!-- @ENGLISH {{{
- <title>Properties</title>
+ <screen>
+$ svn propedit copyright calc/button.c ### exit the editor without changes
+No changes to property 'copyright' on 'calc/button.c'
+$
+</screen>
- <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.</para>
+ <!-- @ENGLISH {{{
+ <para>We should note that, as with other <command>svn</command>
+ subcommands, those related to properties can act on multiple
+ paths at once. This enables you to modify properties on whole
+ sets of files with a single command. For example, we could
+ have done:</para>
+ @ENGLISH }}} -->
+ <para>Обращаем ваше внимание на то, что как и другие команды
+ <command>svn</command>, команды, относящиеся к свойствам
+ могут применяться к нескольким путям за раз. Это дает возможность
+ одной командой изменять свойства целого набора файлов. Например,
+ можно сделать вот так:</para>
- <para>But it doesn't stop there.</para>
+ <screen>
+$ svn propset copyright '(c) 2006 Red-Bean Software' calc/*
+property 'copyright' set on 'calc/Makefile'
+property 'copyright' set on 'calc/button.c'
+property 'copyright' set on 'calc/integer.c'
+…
+$
+</screen>
- <para>In addition to versioning your directories and files,
- Subversion provides interfaces for adding, modifying, and
- removing versioned metadata on each of your versioned
- directories and files. We refer to this metadata as
- <firstterm>properties</firstterm>, and they can be thought of as
- two-column tables that map property names to arbitrary values
- attached to each item in your working copy. Generally speaking,
- the names and values of the properties can be whatever you want
- them to be, with the constraint that the names must be
- 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 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>
- <para>Мы уже рассмотрели как Subversion сохраняет и получает
- разные версии файлов и директорий из хранилища. Целые главы были
- посвящены этой самой фундаментальной части функциональных
- возможностей этого инструмента. И если поддержка версионирования
- этим ограничится, Subversion все равно останется полноценным
- инструментом с точки зрения управления версиями.</para>
-
- <para>Однако версионирование этим не ограничивается.</para>
+ <!-- @ENGLISH {{{
+ <para>All of this property adding and editing isn't really very
+ useful if you can't easily get the stored property value. So
+ the <command>svn</command> program supplies two subcommands
+ for displaying the names and values of properties stored on
+ files and directories. The <command>svn proplist</command>
+ command will list the names of properties that exist on a
+ path. Once you know the names of the properties on the node,
+ you can request their values individually using <command>svn
+ propget</command>. This command will, given a path (or set of
+ paths) and a property name, print the value of the property to
+ the standard output stream.</para>
+ @ENGLISH }}} -->
+ <para>Все эти добавления и редактирования свойств не очень полезны,
+ если нельзя просто узнать значение свойства. Поэтому для показа
+ сохраненных для файлов и директорий имен и значений свойств,
+ программа <command>svn</command> предлагает две подкоманды.
+ Команда <command>svn proplist</command> перечисляет существующие
+ для указанного пути свойства. После того как вы знаете имя свойства,
+ можно, используя <command>svn propget</command>, запросить его
+ значение. Эта команда выведет на стандартный поток ввода-вывода
+ значение свойства для элемента по указанному пути (или путями) и с
+ указанным именем.</para>
- <para>Дополнительно к версионированнию директорий и файлов,
- Subversion предоставляет для каждой версионированной директории
- и файла интерфейс для добавления, изменения и удаления
- версионированных метаданных. К этим метаданным мы обращаемся как
- к <firstterm>свойствам</firstterm>, присоединенным к каждому
- элементу рабочей копии, которые можно представить
- в виде таблицы с двумя столбцами, которая сопоставляет
- имена свойств соответствующим значениям. Вообще, имена
- и значения свойств могут быть тем, чем вы хотите чтобы они были,
- за исключением того, что имена должны быть читаемым текстом.
- И лучшим из всего является то, что они тоже версионированы
- также как и текстовое содержимое файлов. Можно также просто как и
- для текстовых изменений изменять, фиксировать и отменять изменения
- свойств. Отправка и получение измененных свойств происходит точно
- так же как и обычные фиксации и обновления — для этого нет
- необходимости менять обычный порядок действий.</para>
+ <screen>
+$ svn proplist calc/button.c
+Properties on 'calc/button.c':
+ copyright
+ license
+$ svn propget copyright calc/button.c
+(c) 2006 Red-Bean Software
+</screen>
- <!-- @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 {{{
+ <para>There's even a variation of the
+ <command>proplist</command> command that will list both the
+ name and value of all of the properties. Simply supply the
+ <option>-ﳢ-verbose</option> (<option>-v</option>) option.</para>
@ENGLISH }}} -->
- <para>Подобные приведенным выше, свойства используются и Subversion.
- Так же как и произвольные имена свойств и соответствующие им значения,
- имеются у файлов и директорий, каждая правка может иметь
- произвольные свойства, присоединенные к ней. С теми же исключениями
- — читаемое имя и любое бинарное значение. Главное отличие в том,
- что свойства правок не версионируются. Другими словами, если изменить
- значение свойства правки или удалить такое свойство, у Subversion нет
- возможностей для восстановления предыдущего значения.</para>
+ <para>Существует даже вариант команды <command>proplist</command>,
+ который перечисляет как имена, так и значения свойств. Просто
+ добавьте параметр <option>--verbose</option>
+ (<option>-v</option>).</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>
+ <screen>
+$ svn proplist --verbose calc/button.c
+Properties on 'calc/button.c':
+ copyright : (c) 2006 Red-Bean Software
+ license : ================================================================
+Copyright (c) 2006 Red-Bean Software. All rights reserved.
- <!-- @ENGLISH {{{
- <para>In this section, we will examine the utility—both to
- users of Subversion, and to Subversion itself—of property
- support. You'll learn about the property-related
- <command>svn</command> subcommands, and how property
- modifications affect your normal Subversion workflow.
- Hopefully, you'll be convinced that Subversion properties can
- enhance your version control experience.</para>
- @ENGLISH }}} -->
- <para>В этом разделе мы рассмотрим полезность — как для
- пользователя, так и для самой Subversion — поддержки
- свойств. Вы узнаете о командах <command>svn</command>, относящихся к
- свойствам и том как модификация свойств влияет на привычный рабочий
- цикл. Надеемся, вы убедитесь в том, что свойства в Subversion
- расширяют возможности контроля версий.</para>
-
- <!-- =============================================================== -->
- <sect2 id="svn.advanced.props.why">
- <!-- @ENGLISH {{{
- <title>Why Properties?</title>
- @ENGLISH }}} -->
- <title>Зачем нужны свойства?</title>
-
- <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.</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. But the problem here
- is that your collection of files grows in multiples with each
- new photo added to the site.</para>
- @ENGLISH }}} -->
- <para>Скажем, вы хотите разработать веб-сайт, содержащий много
- цифровых фотографий и показывающий их с подписью и датой.
- Набор этих фотографий постоянно изменяется и вы захотите
- по возможности максимально автоматизировать этот сайт. Фотографии
- могут быть большого размера и как обычно делают на таких
- сайтах, для своих посетителей вам будет необходимо показывать
- миниатюры изображений.</para>
-
- <para>Сделать это вы можете с помощью обычных
- файлов. То есть рядом, в директории, вы можете иметь файлы
- <filename>image123.jpg</filename> и
- <filename>image123-thumbnail.jpg</filename>. Либо если вам необходимо
- сохранить то-же имя файла, миниатюры должны будут находиться в
- отдельной директории, например, так
- <filename>thumbnails/image123.jpg</filename>. Подобным-же образом,
- отдельно от основного графического файла, можно хранить описание и
- дату. Проблема здесь в том, что дерево файлов будет многократно
- увеличиваться при каждом добавлении на сайт фотографии.</para>
-
- <!-- @ENGLISH {{{
- <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 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> и у этого файла установлено свойство
- <literal>caption</literal>, <literal>datestamp</literal> и даже
- <literal>thumbnail</literal>. В этом случае рабочая копия выглядит
- гораздо более управляемо — фактически она будет выглядеть
- так, как будто она ничего кроме графических файлов не содержит.
- Однако ваш скрипт автоматизации знает больше. Он знает, что может
- воспользоваться <command>svn</command> (а еще лучше языковой обвязкой
- Subversion — см. <xref
- linkend="svn.developer.usingapi.otherlangs" />) для получения
- дополнительной, необходимой для показа на сайте информации,
- не занимаясь чтением индексного файла или играми с путями
- файлов.</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
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
-This fixes a nasty segfault in the wort frabbing process
+1. Redistributions of source code must retain the above copyright
+notice, this list of conditions, and the recipe for Fitz's famous
+red-beans-and-rice.
…
-</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>
+</screen>
- <!-- =============================================================== -->
- <sect2 id="svn.advanced.props.manip">
<!-- @ENGLISH {{{
- <title>Manipulating Properties</title>
-
- <para>The <command>svn</command> command affords a few ways to
- add or modify file and directory properties. For properties
- with short, human-readable values, perhaps the simplest way to
- add a new property is to specify the property name and value
- on the command-line of the <command>propset</command>
- subcommand.</para>
+ <para>The last property-related subcommand is
+ <command>propdel</command>. Since Subversion allows you to
+ store properties with empty values, you can't remove a
+ property altogether using <command>propedit</command> or
+ <command>propset</command>. For example, this command will
+ <emphasis>not</emphasis> yield the desired effect:</para>
@ENGLISH }}} -->
- <title>Использование свойств</title>
-
- <para>Команда <command>svn</command> предоставляет несколько
- способов добавления или изменения свойств файлов и директорий.
- Свойства с короткими, читаемыми значениями, наверное проще всего
- добавить указав имя и значение свойства в командной строке
- подкоманды <command>propset</command>.</para>
+ <para>Последней, относящейся к свойствам подкомандой является
+ <command>propdel</command>. Не смотря на то, что Subversion
+ позволяет сохранять свойства с пустыми значениями, полностью
+ удалить свойство, используя <command>propedit</command> или
+ <command>propset</command>, нельзя. Например, такая команда
+ не даст желаемого эффекта:</para>
<screen>
-$ svn propset copyright '(c) 2003 Red-Bean Software' calc/button.c
-property 'copyright' set on 'calc/button.c'
+$ svn propset license '' calc/button.c
+property 'license' set on 'calc/button.c'
+$ svn proplist --verbose calc/button.c
+Properties on 'calc/button.c':
+ copyright : (c) 2006 Red-Bean Software
+ license :
$
</screen>
<!-- @ENGLISH {{{
- <para>But we've been touting the flexibility that Subversion
- offers for your property values. And if you are planning to
- have a multi-line textual, or even binary, property value, you
- probably do not want to supply that value on the command-line.
- So the <command>propset</command> subcommand takes a
- <option>-ﳢ-file</option> (<option>-F</option>) option for
- specifying the name of
- a file which contains the new property value.</para>
+ <para>You need to use the <command>propdel</command> subcommand
+ to delete properties altogether. The syntax is similar to the
+ other property commands:</para>
@ENGLISH }}} -->
- <para>Однако мы уже знаем о гибкости, предлагаемой Subversion
- для значений свойств. И если вам необходимо иметь многострочное
- текстовое, или даже бинарное значение свойства, передавать
- такое значение через командную строку не удобно. Для
- таких случаев команда <command>propset</command> имеет
- параметр <option>--file</option> (<option>-F</option>), указывающий
- имя файла, содержащего новое значение свойства.</para>
+ <para>Для полного удаления свойств необходимо использовать
+ подкоманду <command>propdel</command>. Ее синтаксис такой же
+ как и у других команд работы со свойствами:</para>
<screen>
-$ svn propset license -F /path/to/LICENSE calc/button.c
-property 'license' set on 'calc/button.c'
+$ svn propdel license calc/button.c
+property 'license' deleted from 'calc/button.c'.
+$ svn proplist --verbose calc/button.c
+Properties on 'calc/button.c':
+ copyright : (c) 2006 Red-Bean Software
$
</screen>
<!-- @ENGLISH {{{
- <para>There are some restrictions on the names you can use for
- properties. A property name must start with a letter, a colon
- (<literal>:</literal>), or an underscore
- (<literal>_</literal>); after that, you can also use digits,
- hyphens (<literal>-</literal>), and periods
- (<literal>.</literal>).
+ <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>If you're familiar with XML, this is pretty much the
- ASCII subset of the syntax for XML "Name".</para>
- </footnote>
- </para>
- @ENGLISH }}} -->
- <para>Для имен свойств существует ряд ограничений. Имя свойства должно
- начинаться с буквы, двоеточия (<literal>:</literal>) или подчеркивания
- (<literal>_</literal>); дальше можно использовать цифры, тире
- (<literal>-</literal>) и точки (<literal>.</literal>).
- <footnote>
- <para>Если вы знакомы с XML, то синтаксис XML "Name" использует
- практически тот же ASCII набор.</para>
- </footnote>
- </para>
-
- <!-- @ENGLISH {{{
- <para>In addition to the <command>propset</command> command, the
- <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>
- @ENGLISH }}} -->
- <para>Дополнительно к команде <command>propset</command>,
- <command>svn</command> имеет команду <command>propedit</command>.
- Эта команд