The decision on when to


The decision on when to fire off a contextual diff or merge as part of a larger Subversion operation is made entirely by Subversion, and is affected by, among other things, whether or not the files being operated on are human-readable as determined by their svn:mime-type property. This means, for example, that even if you had the niftiest Microsoft Word-aware differencing or merging tool in the Universe, it would never be invoked by Subversion so long as your versioned Word documents had a configured MIME type that denoted that they were not human-readable (such as application/msword). For more about MIME type settings, see лsvn:mime-type╗

Последующий пример предполагает наличие у вас работающих Subversion клиента для командной строки svn и инструмента администрирования svnadmin. Кроме этого он рассчитан на то, что вы используете Subversion версии 1.2 или более поздней (для того, чтобы это проверить, выполните svn --version).
Subversion хранит всю версионированную информацию в центральном хранилище. Для начала, создадим новое хранилище:
$ svnadmin create /path/to/repos $ ls /path/to/repos conf/ dav/ db/ format hooks/ locks/ README.txt Эта команда создает новую директорию /path/to/repos содержащую Subversion хранилище. Убедитесь, что эта директория находится на локальном диске, не на сетевой шаре. Преимущественно в эта новая директория (кроме прочего) содержит набор файлов базы данных. Вы не увидите своих версионированных файлов если вы загляните внутрь. Больше информации о создании и поддержке хранилища ищите в Глава 5, Администрирование хранилища.
У Subversion нет понятия <проект>. Хранилище является просто виртуальной версионированной файловой системой, большое дерево файлов, которое может содержать все, что угодно. Одни администраторы предпочитают держать в хранилище только один проект, другие держать в хранилище множество проектов, размещая их в отдельных директориях. Достоинства каждого из подходов рассмотрены в . В любом случае, хранилище управляет только файлами и директориями, оставляя за человеком право интерпретировать отдельные директории как <проекты>. Поэтому, если в тексте книги вы встретите упоминание проекта, помните, что имеется в виду просто директория (или несколько директорий) хранилища.
В этом примере мы подразумеваем наличие у вас какого то проекта (набора файлов или директорий), который вы хотите импортировать в только что созданное Subversion хранилище. Начните с объединения их в отдельной директории названой myproject (или как-то иначе). По причинам, которые будут ясны позже (см. Глава 4, Ветвление и слияние), ваше дерево проекта должно содержать три директории верхнего уровня с названиями branches, tags и trunk. Вся ваша информация должна находиться в директории trunk, а директории branches и tags должны быть пустыми:
/tmp/myproject/branches/ /tmp/myproject/tags/ /tmp/myproject/trunk/ foo.c bar.c Makefile : Использовать поддиректории branches, tags и trunk не обязательно. Просто такой подход чаще всего используется и вероятнее всего в дальнейшем вы будете использовать именно его.
Как только вы получите готовое дерево данных, импортируйте его в хранилище при помощи команды svn import (см. ):
$ svn import /tmp/myproject file:///path/to/repos/myproject -m "initial import" Adding /tmp/myproject/branches Adding /tmp/myproject/tags Adding /tmp/myproject/trunk Adding /tmp/myproject/trunk/foo.c Adding /tmp/myproject/trunk/bar.c Adding /tmp/myproject/trunk/Makefile : Committed revision 1. $ Теперь в хранилище находится это дерево данных. Как было отмечено ранее, вы не увидите своих файлов если загляните в хранилище напрямую; все хранится в базе данных. Однако сейчас воображаемая файловая системы хранилища имеет директорию верхнего уровня с названием myproject которая содержит вашу информацию.
Обратите внимание на то, что первоначальная директория /tmp/project остается без изменений; Subversion о ней не знает. (Фактически, при желании, вы можете даже удалить этот каталог.) Чтобы начать работать с информацией хранилища вам нужно создать новую <рабочую копию> информации, своего рода частное рабочее пространство. Попросите Subversion создать рабочую копию директории myproject/trunk хранилища:
$ svn checkout file:///path/to/repos/myproject/trunk myproject A myproject/foo.c A myproject/bar.c A myproject/Makefile : Checked out revision 1. Сейчас у вас в новой директории myproject есть личная копия части хранилища. В рабочей копии вы можете редактировать файлы, а затем зафиксировать внесенные изменения в хранилище.
  • Откройте свою рабочую копию и отредактируйте содержимое файлов.
  • Выполните svn diff чтобы увидеть объединенный diff внесенных изменений.
  • Выполните svn commit для фиксации новой версии ваших файлов в хранилище.
  • Выполните svn update для приведения рабочей копии в <актуальное> состояние по отношению к хранилищу.
Для получения полного списка возможных действий с рабочей копией прочтите Глава 3, Экскурсия по Subversion.
После этого вы можете сделать ваше хранилище доступным для других через сеть. См. Глава 6, Настройка сервера для знакомства с различными типами доступных серверных процессов и методами их настройки.
Пред. Уровень выше След.
Компоненты Subversion Содержание Глава 2. Основные понятия



Замечание, относящееся к окружающему тексту.




Вы можете копировать файлы только внутри одного хранилища. Subversion не поддерживает межхранилищного копирования.



Subversion does not support moving between working copies and URLs. In addition, you can only move files within a single repository-Subversion does not support cross-repository moving.
WC -> WCMove and schedule a file or directory for addition (with history).
URL -> URLComplete server-side rename.



By default, you cannot modify revision properties in a Subversion repository. Your repository administrator must explicitly enable revision property modifications by creating a hook named pre-revprop-change. See for more information on hook scripts.
Пред. Уровень выше След.
svn proplist Содержание svn resolved



If you provide no targets to svn revert, it will do nothing-to protect you from accidentally losing changes in your working copy, svn revert requires you to provide at least one target.
Пред. Уровень выше След.
svn resolved Содержание svn status



--show-updates only places an asterisk next to items that are out of date (that is, items that will be updated from the repository if you run svn update). --show-updates does not cause the status listing to reflect the repository's version of the item.
And finally, the most information you can get out of the status subcommand:
$ svn status --show-updates --verbose wc M 965 938 sally wc/bar.c * 965 922 harry wc/foo.c A + 965 687 harry wc/qax.c 965 687 harry wc/zig.c Head revision: 981 For many more examples of svn status, see .
Пред. Уровень выше След.
svn revert Содержание svn switch


╤юфхЁцрэшх Ёрчфхыр