Наверное, команду svn status вы будете использовать чаще чем любую другую команду Subversion.

При запуске svn status без параметров в корневой директории рабочей копии, будут найдены все сделанные вами файловые и структурные изменения. Ниже приведены примеры различных буквенных кодов, возвращаемых svn status. (Обратите внимание на то, что текст следующий за # на самом деле svn status не печатает.)

  L     some_dir            # svn оставила блокировку в .svn-области для some_dir
M       bar.c               # содержимое bar.c имеет локальные изменения
 M      baz.c               # в baz.c есть изменения в свойствах, а в содержимом нет
X       3rd_party           # директория является частью внешней зависимости
?       foo.o               # svn не управляет foo.o
!       some_dir            # svn управляет этим элементом, но он отсутствует или не поврежден
~       qux                 # элемент версионировался как файл/директория/ссылка, но тип был изменен
I       .screenrc           # svn не управляет этим элементом и настроена на его игнорирование
A  +    moved_dir           # добавлен с историей своего происхождения
M  +    moved_dir/README    # добавлен с историей и имеет локальные изменения
D       stuff/fish.c        # файл запланирован для удаления
A       stuff/loot/bloo.h   # файл запланирован для добавления
C       stuff/loot/lump.c   # файл имеет текстовый конфликт с момента обновления
 C      stuff/loot/glub.c   # файл имеет конфликт в свойствах с момента обновления
R       xyz.c               # файл запланирован для замены
    S   stuff/squawk        # файл или директория были переключены на ветку
     K  dog.jpg             # файл заблокирован локально; присутствует маркер блокирования
     O  cat.jpg             # файл заблокирован в хранилище другим пользователем
     B  bird.jpg            # файл заблокирован локально, но блокировка была нарушена
     T  fish.jpg            # файл заблокирован локально, но блокировка была снята

svn status печатает пять колонок букв, затем несколько пробелов, затем имя файла или директории. Первая колонка показывает статус файла или директории и/или ее содержимого. Коды используемые здесь:

Вторая колонка показывает статус свойств файлов и директорий (больше о свойствах см. в «Свойства»). Если во второй колонке показывается M свойства были изменены. Если в этой колонке показывается C это значит, что свойства этого файла находятся в состоянии конфликта, который должен быть решен до фиксации изменений в хранилище. Во всех других случаях будет выведен пробел.

Третья колонка может содержать только пробел или L, это значит, что у директории заблокирована рабочая область .svn. Вы увидите L если запустите svn status в директории, в которой выполняется svn commit — например, когда вы редактируете лог-сообщение.

Четвертая колонка может содержать только пробел или +, это означает, что элемент был запланирован для «добавления с историей». Это может быть файл или корень скопированной директории. + означает, что элемент является частью поддерева запланированного для «добавления с историей», т. е. одна из родительских директорий была скопирована и этот элемент просто ее часть. M  + означает, что элемент является частью поддерева запланированного для «добавления с историей» and имеет локальные изменения. При выполнении фиксации, в начале родительская директория будет «добавлена с историей», что означает автоматическое наличие файла в копии. После этого в копию будут загружены локальные изменения.

Пятая колонка может содержать только пробел или S. Это символизирует то, что файл или директория были переключены с пути остальной рабочей копии на ветку (используя svn switch).

Шестая колонка показывает информацию о блокировках, которые подробно рассмотрены в «Locking». (Это не те блокировки, которые отмечаются L в третьей колонке; см. Three meanings of «lock»)

Если вы укажите конкретный путь для svn status, вы получите информацию только об этом элементе:

$ svn status stuff/fish.c
D      stuff/fish.c

Кроме того, svn status имеет параметр --verbose (-v), который покажет вам статус каждого элемента в рабочей копии, даже если он не менялся:

$ svn status --verbose
M               44        23    sally     README
                44        30    sally     INSTALL
M               44        20    harry     bar.c
                44        18    ira       stuff
                44        35    harry     stuff/trout.c
D               44        19    ira       stuff/fish.c
                44        21    sally     stuff/things
A                0         ?     ?        stuff/things/bloo.h
                44        36    harry     stuff/things/gloo.c

Это «длинная форма» представления вывода svn status. Первая колонка та же самая, а вот вторая колонка показывает рабочую правку элемента. Третья и четвертая колонки показывают правку в которой элемент последний раз изменялся и кто делал эти изменения.

Ни один из указанных выше вызовов svn status не обращается к хранилищу, они работают только локально, сравнивая метаданные директории .svn с рабочей копией. Отметим, что есть параметр --show-updates (-u), указывающий на соединение с хранилищем и добавляющий информацию об устаревании элементов:

$ svn status --show-updates --verbose
M      *        44        23    sally     README
M               44        20    harry     bar.c
       *        44        35    harry     stuff/trout.c
D               44        19    ira       stuff/fish.c
A                0         ?     ?        stuff/things/bloo.h
Status against revision:   46

Обратите внимание на две звездочки: если сейчас вы запустите svn update вы получите изменения для README и trout.c. Это очень полезная информация — перед фиксацией вам необходимо обновить и получить изменения с сервера для README, или же хранилище отклонит вашу фиксацию как не соответствующую актуальному состоянию. (Подробнее об этом чуть позже.)

Еще один механизм для анализа изменений, это команда svn diff. Увидеть как именно вы изменили элементы можно запустив svn diff без аргументов, в результате выведутся изменения файлов в виде единого формата представления различий:^[9]

$ svn diff
Index: bar.c
===================================================================
--- bar.c (revision 3)
+++ bar.c (working copy)
@@ -1,7 +1,12 @@
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <unistd.h>
+
+#include <stdio.h>

 int main(void) {
-  printf("Sixty-four slices of American Cheese...\n");
+  printf("Sixty-five slices of American Cheese...\n");
 return 0;
 }

Index: README
===================================================================
--- README  (revision 3)
+++ README  (working copy)
@@ -193,3 +193,4 @@
+Note to self:  pick up laundry.

Index: stuff/fish.c
===================================================================
--- stuff/fish.c  (revision 1)
+++ stuff/fish.c  (working copy)
-Welcome to the file known as 'fish'.
-Information on fish will be here soon.

Index: stuff/things/bloo.h
===================================================================
--- stuff/things/bloo.h (revision 8)
+++ stuff/things/bloo.h (working copy)
+Here is a new file to describe
+things about bloo.

Команда svn diff формирует свой вывод сравнивая ваши рабочие файлы с кэшированными «нетронутыми» копиями из .svn Весь текст запланированных для добавления файлов показывается как добавленный, а весь текст запланированных для удаления файлов показывается как удаленный.

Вывод происходит в объединенном формате представления различий. При этом удаленные строки предваряются -, а добавленные строки предваряются +. Кроме этого svn diff печатает имена файлов и информацию о сдвиге информации которая необходима программе patch, и следовательно вы можете получать «патчи» перенаправив вывод различий в файл:

$ svn diff > patchfile

Вы можете, например, отправить по электронной почте патч-файл другому разработчику для ознакомления или тестирования перед фиксацией.

Теперь предположим, просмотрев вывод команды diff вы обнаружили, что изменения в README являются ошибочными; возможно, в своем редакторе, вы случайно набрали этот текст, предназначавшийся для другого файла.

Это как раз возможность воспользоваться svn revert.

$ svn revert README
Reverted 'README'

Subversion возвращает файл в состояние, предшествующее модификации, путем замены файла его кэшированной «первоначальной» копией из .svn-области. Кроме того, обратите внимание, что svn revert может отменить любые запланированные операции — например, вы можете прийти к решению таки не добавлять новый файл:

$ svn status foo
?      foo

$ svn add foo
A         foo

$ svn revert foo
Reverted 'foo'

$ svn status foo
?      foo

Или, допустим, вы ошибочно удалили файл из-под контроля версий:

$ svn status README
       README

$ svn delete README
D         README

$ svn revert README
Reverted 'README'

$ svn status README
       README

Объединение конфликтов вручную может показаться пугающим, когда вы делаете это в первый раз, но немного попрактиковавшись это может стать таким же простым, как езда на велосипеде.

Вот пример. По недоразумению, вы и ваш соразработчик Салли, оба одновременно редактируете файл sandwich.txt. Салли зафиксировала свои изменения и когда вы выполните обновление своей рабочей копии, вы получите конфликт и для решения конфликта вам необходимо редактировать sandwich.txt. Для начала, посмотрим на файл:

$ cat sandwich.txt
Top piece of bread
Mayonnaise
Lettuce
Tomato
Provolone
<<<<<<< .mine
Salami
Mortadella
Prosciutto
=======
Sauerkraut
Grilled Chicken
>>>>>>> .r2
Creole Mustard
Bottom piece of bread

Строки знаков меньше чем, знаков равенства и знаков больше чем являются маркерами конфликта. Перед следующей фиксацией, вам необходимо будет убедиться, что они удалены из файла. Текст между первыми двумя маркерами состоит из ваших изменений конфликтующей области:

<<<<<<< .mine
Salami
Mortadella
Prosciutto
=======

Текст между вторым и третьим маркером конфликта — это текст из фиксации Салли:

=======
Sauerkraut
Grilled Chicken
>>>>>>> .r2

Скорее всего вы не захотите просто удалить маркеры конфликта и изменения Салли — она ужасно удивится, когда дойдет до сандвича и не увидит того, что ей нужно. Так, что это тот случай когда вы снимаете трубку или пересекаете офис и объясняете Салли, что не можете получить из итальянского гастронома квашеную капусту. ^[11] После того как вы согласовали изменения, вам нужно выполнить фиксацию, отредактируйте ваш файл и удалите маркеры конфликта.

Top piece of bread
Mayonnaise
Lettuce
Tomato
Provolone
Salami
Mortadella
Prosciutto
Creole Mustard
Bottom piece of bread

Теперь выполните svn resolved и вы готовы к фиксации изменений:

$ svn resolved sandwich.txt
$ svn commit -m "Go ahead and use my sandwich, discarding Sally's edits."

Обратите внимание на то, что svn resolved, в отличие от большинства команд с которыми мы имели дело в этой главе, требует аргумент. В любом случае будьте осторожны и выполняйте svn resolved тогда, когда убеждены, что исправили конфликт в файле — после того как временные файлы будут удалены, Subversion позволит вам зафиксировать файл даже если он все еще содержит маркеры конфликта.

Если вы станете в тупик при редактировании конфликтующего файла, вы всегда можете обратиться к трем файлам, которые Subversion создает в рабочей копии — включая ваш файл в том виде в каком он был до обновления. Для анализа этих трех файлов, вы даже можете воспользоваться программами для объединения от сторонних разработчиков.

Если вы получили конфликт и решили отказаться от своих изменений, вы можете просто скопировать один из временных файлов созданных Subversion поверх файла в рабочей копии:

$ svn update
C  sandwich.txt
Updated to revision 2.
$ ls sandwich.*
sandwich.txt  sandwich.txt.mine  sandwich.txt.r2  sandwich.txt.r1
$ cp sandwich.txt.r2 sandwich.txt
$ svn resolved sandwich.txt

Если вы получили конфликт и вместо анализированния решаете отбросить изменения и начать сначала, просто отмените ваши изменения:

$ svn revert sandwich.txt
Reverted 'sandwich.txt'
$ ls sandwich.*
sandwich.txt

Обратите внимание, что когда вы возвращаете файл к предыдущему состоянию, вам не нужно выполнять svn resolved.