[svnbook commit] r1847 - trunk/src/ru/book
FLamY
svnbook-dev at red-bean.com
Mon Nov 21 22:26:55 CST 2005
Author: FLamY
Date: Mon Nov 21 22:26:54 2005
New Revision: 1847
Modified:
trunk/src/ru/book/ch02.xml
trunk/src/ru/book/foreword.xml
Log:
Corrected some mistakes. Uniforming the style of text.
Modified: trunk/src/ru/book/ch02.xml
==============================================================================
--- trunk/src/ru/book/ch02.xml (original)
+++ trunk/src/ru/book/ch02.xml Mon Nov 21 22:26:54 2005
@@ -64,7 +64,7 @@
информации. В ее основе хранилище, являющееся центром хранения
данных. Хранилище хранит информацию в форме
<firstterm>дерева файлов</firstterm> — типичном
- представлении файлов и директорий. Любое количество
+ представлении файлов и каталогов. Любое количество
<firstterm>клиентов</firstterm> подключается к хранилищу и
читает или записывает эти файлы. Записывая данные, клиент
делает информацию доступной для остальных; читая данные
@@ -95,8 +95,8 @@
совсем обычного. Что делает хранилище Subversion особенным — это то,
что он <emphasis>запоминает каждое внесенное изменение</emphasis>:
любое изменение любого файла, равно как изменения в самом дереве
- директорий, такие как добавление, удаление и реорганизация файлов и
- директорий.</para>
+ каталогов, такие как добавление, удаление и реорганизация файлов и
+ каталогов.</para>
<!-- @ENGLISH {{{
<para>When a client reads data from the repository, it normally
@@ -116,7 +116,7 @@
последнюю версию дерева файлов. Но клиент также имеет возможность
просмотреть <emphasis>предыдущие</emphasis> состояния файловой системы.
Например, клиент может запросить такие данные как, <quote>Что
- содержала эта директория в прошлую среду?</quote> или <quote>Кто
+ содержал этот каталог в прошлую среду?</quote> или <quote>Кто
был последним изменявшим этот файл и какие вносились изменения?</quote>
Вопросы подобного типа основные для любой <firstterm>системы
контроля версий</firstterm>: системы разработанной для записи и
@@ -371,7 +371,7 @@
альтернативы блокированию. В этой модели каждый пользовательский
клиент связывается с хранилищем проекта и создает персональную
<firstterm>рабочую копию</firstterm> — локальное отражение
- файлов и директорий хранилища. После этого пользователи работают
+ файлов и каталогов хранилища. После этого пользователи работают
параллельно, изменяя свои личные копии. В конце концов, личные копии
сливаются в новую, финальную версию. Обычно система управления
версиями помогает в слиянии, но, разумеется, за его корректное
@@ -470,7 +470,7 @@
работать параллельно, не тратя время на ожидание друг друга. При
работе над одними и теми же файлами оказывается, что большинство
параллельно вносимых изменений совсем не перекрываются; конфликты
- являются не частыми. И время, которое было потрачено на разрешение
+ бывают редко. И время, которое было потрачено на разрешение
конфликтов значительно меньше времени отнимаемого блокирующей
системой.</para>
@@ -523,14 +523,14 @@
@ENGLISH }}} -->
<para>Модель копирование-изменение-слияние основывается на
предположении о том, что файлы контекстно-объединяемы: это так
- если большинство файлов в хранилище — основанные на строках
- текстовые файлы (такие как исходный код программы). Но для файлов
+ если большинство файлов в хранилище —
+ текстовые файлы (например исходный код программы). Но для файлов
бинарных форматов, таких как графические или звуковые, как правило
не возможно объединить конфликтующие изменения. В таких ситуациях
пользователям действительно необходимо быть внимательными при
изменении файла. Без раздельного доступа кто-то может впустую
- потратить время на изменения которые в конце концов
- потеряются.</para>
+ потратить время на изменения, которые в конце концов
+ будут потеряны.</para>
<!-- @ENGLISH {{{
<para>While CVS and Subversion are still primarily
@@ -538,8 +538,8 @@
lock an occasional file and provide mechanisms for this.
See <xref linkend="svn.advanced.locking"/>.</para>
@ENGLISH }}} -->
- <para>Так как CVS и Subversion в первую очередь системы типа
- копирование-изменение-слияние в них обоих признается необходимость
+ <para>Так как и CVS, и Subversion, — в первую очередь системы типа
+ копирование-изменение-слияние, то в них обоих признается необходимость
блокирования определенных файлов и предлагаются механизмы для
этого. См. <xref linkend="svn.advanced.locking"/>.</para>
@@ -565,7 +565,7 @@
this section, we'll show real examples of Subversion being
used.</para>
@ENGLISH }}} -->
- <para>Время перейти от абстракций к конкретике. В этом разделе мы покажем
+ <para>Настало время перейти от абстракций к конкретике. В этом разделе мы покажем
реальные примеры использования Subversion.</para>
<!-- =============================================================== -->
@@ -595,13 +595,13 @@
working copies of the same project.</para>
@ENGLISH }}} -->
<para>Рабочая копия Subversion представляет собой обычное дерево
- директорий на вашем компьютере, содержащее набор файлов. Вы можете
+ каталогов на вашем компьютере, содержащее набор файлов. Вы можете
по-своему усмотрению редактировать эти файлы и, если это исходные коды,
вы можете обычным способом скомпилировать программу. Ваша рабочая
копия это ваше личное рабочее пространство: Subversion как не
смешивает вносимые другими изменения с вашими, так и не делает
- доступными для других изменения сделанные вами, пока вы явно не
- укажите сделать это. Вы даже можете иметь несколько рабочих копий
+ доступными для других изменения сделанные вами, пока вы не
+ прикажете сделать это. Вы даже можете иметь несколько рабочих копий
одного и того же проекта.</para>
<!-- @ENGLISH {{{
@@ -636,10 +636,10 @@
@ENGLISH }}} -->
<para>Рабочая копия содержит несколько дополнительных файлов, созданных
и обслуживаемых Subversion, которые помогают ей при выполнении этих
- команд. В частности, каждая директория в вашей рабочей копии содержит
- поддиректорию с именем <filename>.svn</filename> называемую
- <firstterm>административной директорией</firstterm> рабочей копии.
- Файлы в административной директории помогают Subversion определить
+ команд. В частности, каждый каталог в вашей рабочей копии содержит
+ подкаталог с именем <filename>.svn</filename> который называется
+ <firstterm>служебным каталогом</firstterm> рабочей копии.
+ Файлы в служебном каталоге помогают Subversion определить
какие файлы рабочей копии содержат неопубликованные изменения, и какие
файлы устарели по отношению к файлам других участников.</para>
@@ -652,9 +652,9 @@
@ENGLISH }}} -->
<para>Как правило, хранилище Subversion содержит файлы (или исходный
код) нескольких проектов; обычно каждый проект представляется в виде
- поддиректории файловой системы хранилища. При таком подходе,
- пользовательская рабочая копия обычно соответствует отдельной
- поддиректории хранилища.</para>
+ подкаталога файловой системы хранилища. При таком подходе,
+ пользовательская рабочая копия обычно соответствует отдельному
+ подкаталогу хранилища.</para>
<!-- @ENGLISH {{{
<para>For example, suppose you have a repository that contains
@@ -663,10 +663,10 @@
top-level subdirectory, as shown in <xref
linkend="svn.basic.in-action.wc.dia-1"/>.</para>
@ENGLISH }}} -->
- <para>Например, предположим, что у вас есть хранилище, содержащий два
- программных проекта <literal>paint</literal> и
- <literal>calc</literal>. Каждый проект располагается в своей
- собственной директории, как показано на
+ <para>Например, предположим, что у вас есть хранилище, содержащее два
+ программных проекта: <literal>paint</literal> и
+ <literal>calc</literal>. Каждый проект располагается в своем
+ собственном каталоге, как показано на
<xref linkend="svn.basic.in-action.wc.dia-1"/>.</para>
<figure id="svn.basic.in-action.wc.dia-1">
@@ -686,9 +686,9 @@
if you check out <filename>/calc</filename>, you will get a
working copy like this:</para>
@ENGLISH }}} -->
- <para>Для того чтобы сделать рабочую копию, вам нужно
- <firstterm>заполучить</firstterm> какую-либо из поддиректорий
- хранилища. (Возможно, термин <firstterm>заполучить</firstterm>
+ <para>Для того чтобы создать рабочую копию, вам нужно
+ <firstterm>получить</firstterm> какую-либо из подкаталогов
+ хранилища. (Возможно, термин <firstterm>получить</firstterm>
звучит как что-то связанное с блокированием или резервированием
ресурсов, но это не так; эта команда просто создает для вас личную
копию проекта.) Например, если вы получите
@@ -715,11 +715,11 @@
extra information needed by Subversion, as mentioned
earlier.</para>
@ENGLISH }}} -->
- <para>Буквы А говорят о том, что Subversion добавляет этот элемент в
- вашу рабочую копию. Теперь у вас есть личная копия директории
+ <para>Буквы А говорят о том, что Subversion добавил этот элемент в
+ вашу рабочую копию. Теперь у вас есть личная копия каталога
<filename>/calc</filename> хранилища, с одним небольшим добавлением
- — папкой с названием <filename>.svn</filename> — содержащей, как было
- указано выше, дополнительную информацию необходимую Subversion.</para>
+ — каталогом <filename>.svn</filename>, содержащим, как было
+ указано выше, дополнительную информацию, необходимую Subversion.</para>
<sidebar id="svn.basic.in-action.wc.sb-1">
<!-- @ENGLISH {{{
@@ -738,7 +738,7 @@
способами — на локальном диске или через ряд сетевых протоколов.
Местоположение хранилища всегда определяется при помощи URL.
Таблица <xref linkend="svn.basic.in-action.wc.tbl-1"/>
- показывает соответствие разных URL-схем существующим
+ показывает соответствие разных URL-схем возможным
методам доступа.</para>
<table id="svn.basic.in-action.wc.tbl-1">
@@ -772,7 +772,8 @@
<entry>access via WebDAV protocol to Subversion-aware
Apache server</entry>
@ENGLISH }}} -->
- <entry>доступ к серверу Apache через протокол WebDAV</entry>
+ <entry>доступ через протокол WebDAV (если Subversion-сервер
+ работает через Apache)</entry>
</row>
<row>
<entry><literal>https://</literal></entry>
@@ -824,11 +825,11 @@
<firstterm>committing</firstterm> (or <firstterm>checking
in</firstterm>) changes to the repository.</para>
@ENGLISH }}} -->
- <para>Предположим вы внесли изменения в <filename>button.c</filename>.
- Так как директория <filename>.svn</filename> помнит дату изменения
+ <para>Предположим, вы внесли изменения в <filename>button.c</filename>.
+ Так как каталог <filename>.svn</filename> помнит дату изменения
файла и его оригинальное содержимое, Subversion может сказать о том,
что вы изменили файл. Subversion не публикует ваших изменений пока
- вы явно не укажете этого. Публикация ваших изменений более известна
+ вы не прикажете это сделать. Публикация ваших изменений более известна
как <firstterm>фиксация</firstterm> (или <firstterm>checking
in</firstterm>) изменений в хранилище.</para>
@@ -854,7 +855,7 @@
@ENGLISH }}} -->
<para>Теперь ваши изменения в <filename>button.c</filename>
зафиксированы в хранилище; если другой пользователь
- создаст рабочую копию <filename>/calc</filename> он увидит
+ создаст рабочую копию <filename>/calc</filename>, он увидит
ваши изменения в последней версии файла.</para>
<!-- @ENGLISH {{{
@@ -865,10 +866,10 @@
unchanged; Subversion only modifies working copies at the
user's request.</para>
@ENGLISH }}} -->
- <para>Предположим у вас есть со-разработчик, Салли, которая
+ <para>Предположим, у вас есть партнер, Салли, которая
создала рабочую копию <filename>/calc</filename> одновременно
с вами. Когда вы зафиксировали изменения в
- <filename>button.c</filename> рабочая копия Салли осталась не
+ <filename>button.c</filename>, рабочая копия Салли осталась не
измененной; Subversion модифицирует рабочие копии только
по запросу пользователей.</para>
@@ -881,10 +882,10 @@
it out.</para>
@ENGLISH }}} -->
<para>Для приведения рабочей копии в актуальное состояние, Салли
- может попросить Subversion <firstterm>обновить</firstterm> ее
+ может попросить Subversion <firstterm>обновить</firstterm> её
рабочую копию, используя команду Subversion
<command>update</command>. Это внедрит ваши изменения в ее рабочую
- копию в месте с другими имениями, которые были зафиксированы с момента
+ копию вместе с другими изменениями, которые были зафиксированы с момента
когда она создавала рабочую копию.</para>
<screen>
@@ -909,11 +910,10 @@
@ENGLISH }}} -->
<para>Вывод команды <command>svn update</command> говорит, что
Subversion обновила содержимое <filename>button.c</filename>.
- Обратите внимание, что Салли не нужно указывать какой файл обновить;
- для определения того, какие файлы необходимо привести в актуальное
- состояние, Subversion использует информацию в директории
- <filename>.svn</filename> и дополнительно информацию в
- хранилище.</para>
+ Обратите внимание, что Салли не должна указывать, какой файл обновить;
+ для определения файлов, которые необходимо привести в актуальное
+ состояние, Subversion использует информацию в каталоге
+ <filename>.svn</filename>, а также информацию из хранилища.</para>
</sect2>
@@ -935,11 +935,11 @@
unit.</para>
@ENGLISH }}} -->
<para>Операция <command>svn commit</command> может опубликовать
- изменения любого количества файлов и директорий за одну
- атомарную транзакцию. В своей рабочей копии вы можете менять
+ изменения любого количества файлов и каталогов за одну
+ атомарную операцию. В своей рабочей копии вы можете менять
содержимое файлов, создавать, удалять, переименовывать и
- копировать файлы и директории, а за тем зафиксировать за
- раз полный набор изменений.</para>
+ копировать файлы и каталоги, а затем зафиксировать все
+ изменения за один раз.</para>
<!-- @ENGLISH {{{
<para>In the repository, each commit is treated as an atomic
@@ -949,10 +949,10 @@
network problems, and other users' actions.</para>
@ENGLISH }}} -->
<para>В хранилище каждая фиксация отражается как атомарная
- транзакция: либо изменения вносятся полностью, либо не вносятся
- вовсе. Subversion ведет себя так, принимая в расчет возможные
- программные сбои, системные сбои, сетевые проблемы и неверные
- действия пользователя.</para>
+ операция: либо изменения вносятся полностью, либо не вносятся
+ вообще. Subversion ведёт себя так, принимая в расчет возможные
+ сбои в программах, системные сбои, проблемы с сетью, а также
+ неверные действия пользователя.</para>
<!-- @ENGLISH {{{
<para>Each time the repository accepts a commit, this creates a
@@ -963,13 +963,13 @@
repository is numbered zero, and consists of nothing but an
empty root directory.</para>
@ENGLISH }}} -->
- <para>Каждый раз когда хранилище получает фиксацию, создается
- новое состояние файловой системы, называемое
+ <para>Каждый раз, когда происходит фиксация, создаётся
+ новое состояние файловой системы, которое называется
<firstterm>правка</firstterm>. Каждая правка получает
- уникальный натуральный номер, на единицу больший номера
+ уникальный номер, на единицу больший номера
предыдущей правки. Начальная правка только что созданного
- хранилища получает номер ноль и не содержит ничего кроме
- пустой корневой директории.</para>
+ хранилища получает номер 0 и не содержит ничего, кроме
+ пустого корневого каталога.</para>
<!-- @ENGLISH {{{
<para><xref linkend="svn.basic.in-action.revs.dia-1"/> illustrates a nice way to
@@ -981,10 +981,10 @@
@ENGLISH }}} -->
<para><xref linkend="svn.basic.in-action.revs.dia-1"/> отлично
иллюстрирует хранилище. Представьте массив номеров правок,
- начинающийся с 0, распространяясь слева на право. Каждый номер
- правки имеет соответствующие дерево файлов, а каждое дерево
+ начинающийся с 0, с направлением слева направо. Каждый номер
+ правки имеет соответствующее дерево файлов, а каждое дерево
представляет собой <quote>снимок</quote> того, как хранилище
- выглядел после фиксации.</para>
+ выглядело после фиксации.</para>
<figure id="svn.basic.in-action.revs.dia-1">
<!-- @ENGLISH {{{
@@ -998,7 +998,7 @@
<!-- @ENGLISH {{{
<title>Global Revision Numbers</title>
@ENGLISH }}} -->
- <title>Сквозные номера правок</title>
+ <title>Глобальные номера правок</title>
<!-- @ENGLISH {{{
<para>Unlike those of many other version control systems,
@@ -1016,7 +1016,7 @@
CVS uses per-file revisions numbers, CVS users might want to
see <xref linkend="svn.forcvs"/> for more details.</para>
@ENGLISH }}} -->
- <para>В отличие от многих других систем контроля версий номера правок
+ <para>В отличие от многих других систем управления версиями, номера правок
в Subversion относятся <emphasis>ко всем</emphasis>, а не только к
отдельно взятым файлам. Каждый номер правки соответствует целому
дереву, отдельному состоянию хранилища после зафиксированного
@@ -1024,9 +1024,9 @@
файловой системы хранилища после выполнения N-ой фиксации. Когда
пользователи Subversion говорят о <quote>правке 5 <filename>foo.c
</filename></quote>, на самом деле речь идет о <quote><filename>
- foo.c</filename> входящем в правку 5</quote>. Замете, что, в общем
- случае, правки N и M файла <emphasis>не обязательно</emphasis>
- будут отличаться. Так как CVS используется пофайловая нумерация
+ foo.c</filename> входящем в правку 5</quote>. Заметьте, что
+ обычно правки N и M файла <emphasis>не обязательно</emphasis>
+ будут отличаться. Поскольку в CVS используется пофайловая нумерация
правок, пользователи CVS могут обратиться за более подробной
информацией к <xref linkend="svn.forcvs"/>.</para>
</sidebar>
@@ -1040,8 +1040,8 @@
@ENGLISH }}} -->
<para>Важно помнить то, что рабочие копии не всегда соответствуют
какой-то одной правке в хранилище; они могут содержать файлы из
- различных правок. Например, вы получили рабочую копию из хранилища,
- у которого самая последняя правка 4:</para>
+ разных правок. Например, вы получили рабочую копию из хранилища,
+ у которого самая последняя правка — 4:</para>
<screen>
calc/Makefile:4
@@ -1057,11 +1057,11 @@
commit will create revision 5 of the repository, and your
working copy will now look like this:</para>
@ENGLISH }}} -->
- <para>На данный момент рабочая директория полностью соответствует
+ <para>На данный момент рабочий каталог полностью соответствует
правке 4 в хранилище. Допустим, что вы внесли изменения в
<filename>button.c</filename>, и зафиксировали эти изменения.
- При отсутствии других фиксаций ваша фиксация создаст правку 5
- хранилища, и теперь ваша рабочая копия выглядит следующим
+ При отсутствии других фиксаций ваша фиксация создаст правку
+ под номером 5, и теперь ваша рабочая копия выглядит следующим
образом:</para>
<screen>
@@ -1098,15 +1098,15 @@
update at the top of your working copy, it will generally
correspond to exactly one revision in the repository.</para>
@ENGLISH }}} -->
- <para>Изменения, внесенные Сэлли в <filename>integer.c</filename> будут
+ <para>Изменения, внесенные Салли в <filename>integer.c</filename> будут
отражены в вашей рабочей копии, и ваши изменения в
<filename>button.c</filename> также будут присутствовать. В этом
примере текст <filename>Makefile</filename> в правках 4, 5 и 6
идентичен, однако, Subversion проставляет номер правки 6 для вашей
- рабочей копии <filename>Makefile</filename> чтобы показать что он
+ рабочей копии <filename>Makefile</filename>, чтобы показать что файл
не устарел. Таким образом, после того как вы выполните полное
- обновление вашей рабочей копии она просто будет соответствовать одной
- правке хранилища.</para>
+ обновление вашей рабочей копии, она будет полностью соответствовать
+ текущему состоянию хранилища.</para>
</sect2>
@@ -1124,8 +1124,8 @@
two essential pieces of information in the
<filename>.svn/</filename> administrative area:</para>
@ENGLISH }}} -->
- <para>Для каждого файла рабочей директории, в административной области
- <filename>.svn/</filename>, Subversion записывает информацию о двух
+ <para>В служебном каталоге <filename>.svn/</filename> для каждого
+ файла рабочего каталога Subversion записывает информацию о двух
важнейших свойствах:</para>
@@ -1146,8 +1146,8 @@
<para>a timestamp recording when the local copy was last
updated by the repository.</para>
@ENGLISH }}} -->
- <para>временной метке, определяющей, когда рабочая копия последний
- раз обновлялась из хранилища.</para>
+ <para>временной (ударение на последний слог) метке, определяющей,
+ когда рабочая копия последний раз обновлялась из хранилища.</para>
</listitem>
</itemizedlist>
@@ -1156,8 +1156,8 @@
Subversion can tell which of the following four states a
working file is in:</para>
@ENGLISH }}} -->
- <para>Получая эту информацию при соединении с хранилищем Subversion
- может сказать в каком из следующих четырех состояний находится рабочий
+ <para>Используя эту информацию при соединении с хранилищем, Subversion
+ может сказать, в каком из следующих четырех состояний находится рабочий
файл:</para>
<variablelist>
@@ -1176,11 +1176,11 @@
<command>svn update</command> of the file will do
nothing.</para>
@ENGLISH }}} -->
- <para>Файл не изменялся в рабочей директории и в хранилище не
+ <para>Файл не изменялся в рабочем каталоге, в хранилище не
фиксировались изменения этого файла со времени создания его
- рабочей правки. Команда <command>svn commit</command> не
- сделает ничего и <command>svn update</command> не сделает
- ничего.</para>
+ рабочей правки. Команды <command>svn commit</command> и
+ <command>svn update</command> никаких операций делать не
+ будут.</para>
</listitem>
</varlistentry>
@@ -1200,11 +1200,11 @@
succeed in publishing your changes, and an <command>svn
update</command> of the file will do nothing.</para>
@ENGLISH }}} -->
- <para>Файл был изменен в рабочей директории а в хранилище не
+ <para>Файл был изменен в рабочей копии, но в хранилище не
фиксировались изменения этого файла после правки, на которой он
основан. Есть локальные изменения, которые не были зафиксированы
- в хранилище, таким образом, <command>svn commit</command>
- выполнит публикацию ваших изменений, а
+ в хранилище, поэтому <command>svn commit</command>
+ выполнит фиксацию ваших изменений, а
<command>svn update</command> не сделает ничего.</para>
</listitem>
</varlistentry>
@@ -1225,9 +1225,9 @@
<command>svn update</command> of the file will fold the
latest changes into your working copy.</para>
@ENGLISH }}} -->
- <para>В рабочей директории файл не изменялся но был изменен в
+ <para>В рабочем каталоге файл не изменялся, но был изменен в
хранилище. Необходимо выполнить обновление файла для того,
- чтобы он соответствовал опубликованной правке. Команда <command>
+ чтобы он соответствовал текущей правке. Команда <command>
svn commit</command> не сделает ничего, а
<command>svn update</command> обновит вашу рабочую копию файла в
соответствии с последними изменениями.</para>
@@ -1252,13 +1252,13 @@
plausible way automatically, it leaves it to the user to
resolve the conflict.</para>
@ENGLISH }}} -->
- <para>Файл был изменен как в рабочей директории, так и в
- хранилище. <command>svn update</command> потерпит неудачу с
- ошибкой <quote>out-of-date</quote>. Файл необходимо сначала
- обновить, <command>svn update</command> попытается объединить
+ <para>Файл был изменен как в рабочем каталоге, так и в
+ хранилище. <command>svn commit</command> потерпит неудачу, выдав
+ ошибку <quote>out-of-date</quote>. Файл необходимо сначала
+ обновить; <command>svn update</command> попытается объединить
локальные изменения с опубликованными. Если Subversion не сможет
- корректно завершить объединение самостоятельно, возможность
- разрешить конфликт будет предоставлена пользователю.</para>
+ самостоятельно совершить объединение, он предложит пользователю
+ разрешить конфликт вручную.</para>
</listitem>
</varlistentry>
</variablelist>
@@ -1270,11 +1270,11 @@
of any item in your working copy. For more information on
that command, see <xref linkend="svn.tour.cycle.examine.status" />.</para>
@ENGLISH }}} -->
- <para>Совсем не обязательно заниматься подобным гаданием, для того, что
- бы узнать состояние любого элемента в рабочей в вашей рабочей копии
- воспользуйтесь командой <command>svn status</command>. За более
- подробной информацией об этой команде обратитесь к <xref
- linkend="svn.tour.cycle.examine.status" />.</para>
+ <para>Может показаться, что следить за актуальным состоянием рабочей
+ копии сложно. Это не так. Для того, чтобы узнать состояние любого
+ элемента в вашей рабочей копии существует команда <command>svn
+ status</command>. За более подробной информацией об этой команде
+ обратитесь к <xref linkend="svn.tour.cycle.examine.status" />.</para>
</sect2>
@@ -1296,20 +1296,20 @@
here's a primer on both why the feature exists and how to make
use of it.</para>
@ENGLISH }}} -->
- <para>Subversion пытается быть гибкой настолько, насколько это возможно.
- В частности, существует возможность иметь рабочую копию, содержащую
- файлы и директории, имеющие смешанные номера рабочих правок. Но к
- сожалению эта гибкость, иногда, смущает некоторых новых
+ <para>Subversion старается быть гибкой настолько, насколько это возможно.
+ Например, существует возможность иметь рабочую копию, содержащую
+ файлы и каталоги, имеющие смешанные номера рабочих правок. Но, к
+ сожалению, эта гибкость иногда смущает некоторых новых
пользователей. Если раньше примеры, показывающие смешанные правки,
- вызывали у вас чувство растерянности, то вот вам руководство, которое
- рассказывает и для чего такая возможность существует и как ее
- использовать.</para>
+ вызывали у вас чувство растерянности, то это руководство, которое
+ рассказывает для чего такая возможность существует и как ее
+ использовать, для вас.</para>
<sect3 id="svn.basic.in-action.mixedrevs.update-commit">
<!-- @ENGLISH {{{
<title>Updates and Commits are Separate</title>
@ENGLISH }}} -->
- <title>Обновления и фиксации существуют независимо</title>
+ <title>Обновления и фиксации отделены друг от друга</title>
<!-- @ENGLISH {{{
<para>One of the fundamental rules of Subversion is that
@@ -1323,9 +1323,9 @@
publish them.</para>
@ENGLISH }}} -->
<para>Одно из фундаментальных правил Subversion заключается в том,
- что <quote>выталкивающее</quote> действие не приводит к
- <quote>затаскиванию</quote> и на оборот. Только то, что вы готовы
- внести изменения в хранилище, не означает, что вы готовы получать
+ что <quote>передающее</quote> действие не приводит к
+ <quote>принимаемому</quote>, и наоборот. То, что вы готовы
+ внести изменения в хранилище, не означает то, что вы готовы принять
изменения от других. А если вы все еще работаете над новыми изменениями,
то <command>svn update</command> изящно объединит изменения из
хранилища с вашими собственными, вместо того, что бы заставлять вас
@@ -1339,9 +1339,9 @@
themselves are versioned.</para>
@ENGLISH }}} -->
<para>Главным побочным эффектом этого правила является то, что
- рабочей копии необходимо вести дополнительный учет при смешивании
- правок и быть терпимой к смешиванию вообще. Тот факт, что директории
- сами по себе являются версионированными, делает это еще более сложным
+ рабочая копия должна вести дополнительный учет при смешивании
+ правок и быть аккуратной при любом смешивании. И то, что каталоги
+ попадают под контроль версий, делает это еще более сложным
для понимания.</para>
<!-- @ENGLISH {{{
@@ -1370,23 +1370,23 @@
can the latest changes be downloaded, and the whole working
copy be marked as revision 15.</para>
@ENGLISH }}} -->
- <para>Допустим, есть рабочая копия, полностью соответствующая
- правке 10. Редактируется файл <filename>foo.html</filename>,
- после чего выполняется команда <command>svn commit</command>,
+ <para>Допустим, у вас есть рабочая копия, полностью соответствующая
+ правке 10. После изменения файла <filename>foo.html</filename>,
+ вы выполняете команду <command>svn commit</command>,
которая создает в хранилище правку 15. После выполнения
- фиксации большинство новых пользователей ожидают, что вся
+ фиксации большая часть новичков ожидают, что вся
рабочая копия будет иметь правку 15, однако это не так.
Между правками 10 и 15 в хранилище могло быть внесено любое
- количество изменений. Так как не выполнялась команда
- <command>svn update</command>, а <command>svn commit</command>
- не загружает изменений, клиент ничего не знает о находящихся в
- хранилище изменениях. С другой стороны, если <command>svn
- commit</command> будет автоматически загружать последние изменения,
- то в этом случае, для всей рабочей копии можно назначить соответствие
- правке 15 — однако нарушится фундаментальное правило,
- согласно которому <quote>выталкивание</quote> и
- <quote>затаскивание</quote> являются независимыми операциями.
- Следовательно, все, что может сделать Subversion клиент, это
+ количество изменений. Так как команда <command>svn update</command>
+ не выполнялась, а <command>svn commit</command>
+ не загружает изменений, клиент ничего не знает о находящихся в
+ хранилище изменениях. С другой стороны, если команда <command>svn
+ commit</command> будет автоматически загружать последние изменения,
+ то всей рабочей копии можно будет назначить соответствующий номер
+ правки - 15. Однако нарушится фундаментальное правило,
+ согласно которому <quote>передача</quote> и
+ <quote>получение</quote> являются независимыми операциями.
+ Следовательно, все, что может сделать клиент Subversion, это
пометить один файл — <filename>foo.html</filename> —
как соответствующий правке 15. Остальная рабочая копия
продолжает соответствовать правке 10. Только при выполнении
@@ -1428,12 +1428,12 @@
the <emphasis>older</emphasis> version of the object is
shown.</para>
@ENGLISH }}} -->
- <title>Смешивание правок это нормально</title>
+ <title>Смешивание правок — это нормально</title>
- <para>Фактически, <emphasis>каждый раз</emphasis>, при
- выполнении <command>svn commit</command>, правки рабочей
+ <para>Фактически, <emphasis>каждый раз</emphasis> при
+ выполнении <command>svn commit</command> правки рабочей
копии смешиваются. Только что зафиксированные элементы
- отмечаются как имеющие большую рабочую правку чем все
+ отмечаются как имеющие больший номер рабочей правки, чем все
остальные. После нескольких фиксаций (без выполнения
обновлений между ними) правки рабочей копии будут полностью
перемешаны. Даже если вы являетесь единственным пользователем
@@ -1447,14 +1447,14 @@
сбить с толку, так как многие команды клиента чувствительны
к рабочей правке элемента, с которым он работает. Например,
команда <command>svn log</command> используется для вывода
- истории изменения файла или директории (см. <xref
+ истории изменения файла или каталога (см. <xref
linkend="svn.tour.history.log"/>). Когда пользователь
вызывает эту команду применительно к объекту рабочей копии,
он ожидает увидеть полную историю этого объекта. Однако
если рабочая правка объекта очень старая (из-за того, что
команда <command>svn update</command> долго не выполнялась)
будет показана история для <emphasis>более старой</emphasis>
- версии компонента рабочей копии.</para>
+ версии этого объекта.</para>
</sect3>
@@ -1474,17 +1474,17 @@
the feature which allows you to move any portion of your
working copy forward and backward in history.</para>
@ENGLISH }}} -->
- <title>Смешивание правок это выгодно</title>
+ <title>Смешивание правок — это полезно</title>
<para>Если у вас очень большой проект, вы можете найти
полезным, время от времени принудительно
<quote>возвращать</quote> части рабочей копии к более
- ранним правкам; как это делается вы узнаете в Главе 3.
+ ранним правкам; как это делается, вы узнаете в Главе 3.
Возможно вы захотите протестировать более раннюю версию
- модуля, находящегося в поддиректории или возможно
- выяснить, в какой момент в конкретном файле появилась
- ошибка. Это сущность <quote>машины времени</quote>
- системы управления версиями — возможность которая
+ модуля, находящегося в подкаталоге или точно
+ узнать, когда в конкретном файле появилась
+ ошибка. Это — <quote>машина времени</quote> —
+ тот аспект системы управления версиями, который
позволяет перемещать в истории любую часть рабочей копии
вперед и назад.</para>
@@ -1493,18 +1493,35 @@
<sect3 id="svn.basic.in-action.mixedrevs.limits">
<!-- @ENGLISH {{{
<title>Mixed revisions have limitations</title>
+ @ENGLISH }}} -->
+ <title>Смешивание правок имеет ограничения</title>
+ <!-- @ENGLISH {{{
<para>However you make use of mixed revisions in your
working copy, there are limitations to this
flexibility.</para>
+ @ENGLISH }}} -->
+ <para>Несмотря на то, что в рабочей копии можно использовать
+ смешивание правок, у этой гибкости существуют
+ ограничения.</para>
+ <!-- @ENGLISH {{{
<para>First, you cannot commit the deletion of a file or
directory which isn't fully up-to-date. If a newer
version of the item exists in the repository, your attempt
to delete will be rejected, to prevent you from
accidentally destroying changes you've not yet
seen.</para>
+ @ENGLISH }}} -->
+ <!-- @ENGLISH {{{
+ <para>Во-первых, нельзя зафиксировать удаление устаревшего
+ файла или каталога. Если в хранилище существует более новая
+ версия элемента, попытка удаления будет отклонена для
+ предотвращения возможности непреднамеренного уничтожения
+ изменений о которых вы не в курсе.</para>
+
+ <!-- @ENGLISH {{{
<para>Second, you cannot commit a metadata change to a
directory unless it's fully up-to-date. You'll learn
about attaching
@@ -1514,25 +1531,13 @@
change to an out-of-date directory may destroy properties
you've not yet seen.</para>
@ENGLISH }}} -->
- <title>Смешивание правок имеет ограничения</title>
-
- <para>Несмотря на то, что в рабочей копии можно использовать
- смешивание правок, в такого рода гибкости существуют
- ограничения.</para>
-
- <para>Во-первых, нельзя зафиксировать удаление устаревшего
- файла или директории. Если в хранилище существует более новая
- версия элемента, попытка удаления будет отклонена, для
- предотвращения возможности непреднамеренного уничтожения
- еще не виденных изменений.</para>
-
- <para>Во-вторых, нельзя зафиксировать измененные метаданные
- для директории которая не полностью обновлена. О присоединении
+ <para>Во-вторых, нельзя зафиксировать изменение метаданных
+ для не обновленного каталога. О присвоении
<quote>свойств</quote> к элементам вы узнаете в Главе 6.
- Рабочая правка директории определяет конкретный набор входящих
+ Рабочая правка каталога определяет конкретный набор входящих
в нее элементов и свойств, поэтому фиксация изменений свойств
- для директории которая устарела может привести к уничтожению
- еще не виденных свойств.</para>
+ для устаревшего каталога может привести к уничтожению
+ свойств о которых вы не знаете.</para>
</sect3>
@@ -1565,7 +1570,7 @@
revision trees.</para>
@ENGLISH }}} -->
<para>Мы ввели такие понятия, как центральное хранилище, рабочая
- копия клиента и массив правок хранилища.</para>
+ копия и массив правок хранилища.</para>
</listitem>
<listitem>
@@ -1576,8 +1581,8 @@
model.</para>
@ENGLISH }}} -->
<para>Мы рассмотрели на нескольких простых примерах, как при помощи
- Subversion два со-разработчика могут публиковать и получать
- изменения друг друга, используя модель
+ Subversion два партнера могут публиковать и получать
+ изменения, сделанные друг другом, используя модель
<quote>копирование-изменение-слияние</quote>.</para>
</listitem>
Modified: trunk/src/ru/book/foreword.xml
==============================================================================
--- trunk/src/ru/book/foreword.xml (original)
+++ trunk/src/ru/book/foreword.xml Mon Nov 21 22:26:54 2005
@@ -88,7 +88,7 @@
для поиска единое целое, наилучшим образом отражающее опыт
пользователей. Здесь требуется терпеливость и внимательность,
присущие естествоиспытателю, а не великие гипотезы и провидческие
- заявления. Главное в этой работе—открытые глаза и
+ заявления. Главное в этой работе — открытые глаза и
аккуратное отношение к записям в блокноте.</para>
<!-- @ENGLISH {{{
@@ -125,7 +125,7 @@
@ENGLISH }}} -->
<para>Устав от ежедневного просмотра одних и тех же вопросов, Бен
провёл месяц в напряжённой работе, и летом 2002 года появилось
- <citetitle>Руководство по Subversion</citetitle>—документ, в
+ <citetitle>Руководство по Subversion</citetitle> — документ, в
котором на 60 страницах описывались все основные приёмы работы с
Subversion. Это руководство не претендовало на полноту, но оно
было включено в поставку Subversion и помогало преодолеть
@@ -151,8 +151,8 @@
написать книгу в обычном смысле слова, от автора к читателю,
начиная с содержания и первого черновика. Но, с другой стороны, у
них также была возможность обращаться у устойчивому
- потоку—да что там говорить, к неуправляемому
- фонтану—материалу, поступающему от будущих читателей.
+ потоку — да что там говорить, к неуправляемому
+ фонтану — материалу, поступающему от будущих читателей.
Subversion уже был в то время в руках тысяч первых пользователей,
которые давали множество отзывов не только о самом Subversion, но
и о документации к нему.</para>
@@ -226,14 +226,14 @@
предвосхищает ваши вопросы, может показаться телепатической, но
вполне может случиться и так, что вы столкнётесь с пробелом в
коллективном знании сообщества и уйдёте с пустыми руками. Лучшее,
- что можно сделать в такой ситуации—отправить письмо на адрес
+ что можно сделать в такой ситуации — отправить письмо на адрес
<email>users at subversion.tigris.org</email> с описанием вашей
проблемы. Авторы по-прежнему читают эту рассылку, они внимательно
наблюдают за вопросами, и, кроме того, сообщество пользователей не
ограничивается тремя людьми, имена которых вынесены на обложку
- этой книги—многие подписчики рассылки также помогают вносить
+ этой книги — многие подписчики рассылки также помогают вносить
исправления и предлагают новый материал для книги. С точки зрения
- сообщества, решение вашей конкретной проблемы—это лишь
+ сообщества, решение вашей конкретной проблемы — это лишь
приятный побочный эффект значительно более обширного проекта, а
именно, постепенного исправления данной книги и самого Subversion
с тем, чтобы как можно ближе соответствовать практике. Эти люди с
More information about the svnbook-dev
mailing list