Подсказка

You should strongly consider using explicit revision numbers in all of your externals definitions. Doing so means that you get to decide when to pull down a different snapshot of external information, and exactly which snapshot to pull. Besides the common sense aspect of not being surprised by changes to third-party repositories that you might not have any control over, using explicit revision numbers also means that as you backdate your working copy to a previous revision, your externals definitions will also revert to the way they looked in that previous revision, which in turn means that the external working copies will be updated to match they way they looked back when your repository was at that previous revision. For software projects, this could be the difference between a successful and a failed build of an older snapshot of your complex codebase.

The support that exists for externals definitions in Subversion today can be a little misleading, though. First, an externals definition can only point to directories, not files. Second, the externals definition cannot point to relative paths (paths like ../../skins/myskin). Third, the working copies created via the externals definition support are still disconnected from the primary working copy (on whose versioned directories the svn:externals property was actually set). And Subversion still only truly operates on non-disjoint working copies. So, for example, if you want to commit changes that you've made in one or more of those external working copies, you must run svn commit explicitly on those working copies—committing on the primary working copy will not recurse into any external ones.

Also, since the definitions themselves use absolute URLs, moving or copying a directory to which they are attached will not affect what gets checked out as an external (though the relative local target subdirectory will, of course, move with renamed directory). This can be confusing—even frustrating—in certain situations. For example, if you use externals definitions on a directory in your /trunk development line which point to other areas of that same line, and then you use svn copy to branch that line to some new location /branches/my-branch, the externals definitions on items in your new branch will still refer to versioned resources in /trunk. Be aware, too, that if you need to re-parent your working copy (using svn switch --relocate), externals definitions will not also be re-parented.

Finally, there might be times when you would prefer that svn subcommands would not recognize or otherwise operate on the external working copies created as the result of externals definition handling. In those instances, you can pass the --ignore-externals option to the subcommand.

Пред.	Уровень выше	След.
Peg and Operative Revisions	Содержание	Vendor branches

Удобно для определения правки, в которой ветка была создана («базовой» правки ветки) использовать параметр --stop-on-copy при запуске svn log. При обычном запуске, эта команда показывает все изменения сделанные в ветке, включая те, которые были сделаны до создания ветки. Поэтому, при таком запуске вы увидите и историю главной линии разработки. Параметр --stop-on-copy остановит вывод лог сообщений как только svn log определит, что целевой объект был скопирован или переименован.

$ svn log --verbose --stop-on-copy \ http://svn.example.com/repos/calc/branches/my-calc-branch … ------------------------------------------------------------------------ r341 | user | 2002-11-03 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines Changed paths: A /calc/branches/my-calc-branch (from /calc/trunk:340) $

Как и ожидалось, последняя правка выведенная этой командой будет правка, в которой директория my-calc-branch была создана путем копированием.

Вот так выглядит завершение объединения:

$ cd calc/trunk $ svn update At revision 405. $ svn merge -r 341:405 http://svn.example.com/repos/calc/branches/my-calc-branch U integer.c U button.c U Makefile $ svn status M integer.c M button.c M Makefile # ...examine the diffs, compile, test, etc... $ svn commit -m "Merged my-calc-branch changes r341:405 into the trunk." Sending integer.c Sending button.c Sending Makefile Transmitting file data ... Committed revision 406.

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

Например, предположим, что на следующей неделе вы решите продолжить работу над веткой, для завершения расширения функциональности или исправления ошибки. После этого, правка HEAD хранилища будет имеет номер 480 и вы готовы выполнить еще одно объединение своей личной копии с главной линией разработки. Однако, как уже было сказано в разделе «Как правильнее всего использовать слияние», нет необходимости объединять изменения которые уже были объединены раньше; нужно объединить только «новые» изменения, появившиеся с момента последнего объединения. Сложность в том, что бы выделить эти новые изменения.

Первым шагом является запуск svn log для главной линии разработки, для того, что бы увидеть сообщение о времени последнего объединения с веткой:

$ cd calc/trunk $ svn log … ------------------------------------------------------------------------ r406 | user | 2004-02-08 11:17:26 -0600 (Sun, 08 Feb 2004) | 1 line Merged my-calc-branch changes r341:405 into the trunk. ------------------------------------------------------------------------ …

Ага! Так как все изменения в ветке, которые делались между правками 341 и 405 уже были объединены с главной линией разработки в правке 406, то теперь вы знаете, что необходимо брать только те изменения ветки, которые были выполнены после этого — сравнивая правки 406 и HEAD.

$ cd calc/trunk $ svn update At revision 480.

# We notice that HEAD is currently 480, so we use it to do the merge: $ svn merge -r 406:480 http://svn.example.com/repos/calc/branches/my-calc-branch U integer.c U button.c U Makefile $ svn commit -m "Merged my-calc-branch changes r406:480 into the trunk." Sending integer.c Sending button.c Sending Makefile Transmitting file data ... Committed revision 481.

Теперь главная линия разработки полностью содержит вторую волну изменений, сделанных в ветке. С этого момента можно либо удалить ветку (об этом мы поговорим позже), либо продолжать работать над веткой, с последующим объединением изменений.

Полезный совет, относящийся к окружающему тексту.

Ваша рабочая копия устарела (или вы что-то в ней локально изменили), но хотите посмотреть HEAD редакцию файла имеющегося в вашей рабочей копии. Подкоманда svn cat автоматически извлечет HEAD редакцию, ей нужено только указать путь к этому файлу:

$ cat foo.c This file is in my local working copy and has changes that I've made. $ svn cat foo.c Latest revision fresh from the repository!

Пред.	Уровень выше	След.
svn blame	Содержание	svn checkout

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

Это рекомендованный способ воскрешать случайно удаленные из хранилища файлы!

$ svn copy file:///tmp/repos/test/far-away near-here A near-here

И наконец, копирование внутри хранилища:

$ svn copy file:///tmp/repos/test/far-away file:///tmp/repos/test/over-there -m "remote copy." Committed revision 9.

Это простейший способ «пометить» редакцию в хранилище—просто выполните svn copy желаемой редакции (хотя обычно это HEAD) в желаемый каталог.

$ svn copy file:///tmp/repos/test/trunk file:///tmp/repos/test/tags/0.6.32-prerelease -m "tag tree" Committed revision 12.

Да, и не волнуйтесь, если забыли вовремя пометить редакцию—вы всегда можете сделать это сославшись на старую редакцию:

$ svn copy -r 11 file:///tmp/repos/test/trunk file:///tmp/repos/test/tags/0.6.32-prerelease -m "Forgot to tag at rev 11" Committed revision 13.

Пред.	Уровень выше	След.
svn commit	Содержание	svn delete

If you run svn log on a specific path and provide a specific revision and get no output at all

$ svn log -r 20 http://svn.red-bean.com/untouched.txt ------------------------------------------------------------------------

That just means that the path was not modified in that revision. If you log from the top of the repository, or know the file that changed in that revision, you can specify it explicitly:

$ svn log -r 20 touched.txt ------------------------------------------------------------------------ r20 | sally | 2003-01-17 22:56:19 -0600 (Fri, 17 Jan 2003) | 1 line Made a change. ------------------------------------------------------------------------

Пред.	Уровень выше	След.
svn lock	Содержание	svn merge

This command is equivalent to an svn copy followed by svn delete.

Subversion has a number of «special» properties that affect its behavior. See «Специальные свойства» for more on these properties.

You can just switch part of your working copy to a branch if you don't want to switch your entire working copy.

Sometimes an administrator might change the «base location» of your repository—in other words, the contents of the repository doesn't change, but the main URL used to reach the root of the repository does. For example, the hostname may change, the URL scheme, or any part of the URL which leads to the repository itself. Rather than checkout a new working copy, you can have the svn switch command «rewrite» the beginnings of all the URLs in your working copy. Use the --relocate option to do the substitution. No file contents are changed, nor is the repository contacted. It's similar to running a Perl script over your working copy .svn/ directories which runs s/OldRoot/NewRoot/.

$ svn checkout file:///tmp/repos test A test/a A test/b … $ mv repos newlocation $ cd test/ $ svn update svn: Unable to open an ra_local session to URL svn: Unable to open repository 'file:///tmp/repos' $ svn switch --relocate file:///tmp/repos file:///tmp/newlocation . $ svn update At revision 3.

If you want to examine an older revision of a single file, you may want to use svn cat.

Пред.	Уровень выше	След.
svn unlock	Содержание	svnadmin

Содержание раздела