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

Источник: T2 SVN commit tutorial
Автор: The T2 SDE Project
Перевод: Лобач Олег

Дважды подумайте перед фиксацией изменений

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

Никогда не фиксируйте код, который не компилируется

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

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

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

Тестируйте ваши изменения перед фиксацией

Запустите приложение и проверьте работу тех участков, которые могли быть затронуты вашими изменениями,чтобы убедиться в том, что изменения ведут себя так, как вы задумывали.

Дважды проверьте то, что фиксируете

Сделайте «svn up» и «svn diff» перед фиксацией. Получите сообщения от SVN о конфликтах, неизвестных файлах и прочее. «svn diff» покажет, что же именно вы фиксируете. Проверьте, действительно ли это то, что вы собирались фиксировать.

Всегда добавляйте содержательные комментарии¹ к фиксации

Комментарии должны быть понятны любому, кто видит только лог. Они не должны зависеть от информации вне контекста фиксации.
Попробуйте описать только те файлы, которые реально затрагиваются в описываемых в комментариях изменениями.

На практике, заносите в комментарии всю важную информацию, которую невозможно увидеть из вывода команды diff.

Система контроля версий не является заменой общению между разработчиками

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

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

Возьмите на себя ответственность за собственные фиксации

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

Не фиксируйте код, который вы не понимаете

Избегайте ситуаций, подобных этой: «Я не знаю, почему он падает, но когда я делаю это, он больше не падает» или «Я не вполне уверен, что это правильно, но во всяком случае у меня это работает».

Если вы не нашли решение проблемы, обсудите её с другими разработчиками.

Не злоупотребляйте своим SVN-аккаунтом, чтобы пропихнуть изменения, отвергнутые другими разработчиками

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

Если вы фиксируете багфикс, учитывайте перенос исправлений в другие ветки

Используйте одинаковый комментарий для обеих фиксаций – основного исправления и переносимого (только дополните комментарий номером ревизии основной фиксации). Таким образом, можно легко увидеть, какие исправления были уже перенесены.

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

Для того, чтобы сохранять вашу систему учета ошибок и SVN синхронизированными, вы должны указывать номер ошибки в комментариях к вашим фиксациям, а затем закрывать ошибку в системе учета.

Создавайте атомарные фиксации

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

Не смешивайте изменения форматирования и изменения кода

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

Похожие записи

• Снова про использование Subversion (0)
• Пользовательские ресурсы для Zend_Application (0)
• Как слить изменения между ветками. Часть 2 (1)
• Как слить изменения между ветками. Часть 1 (1)
• Как и Зачем делать ветки? (3)

• Subversion. Установка и настройка. День первый — взгляд на svn из Linux-а: установка, создание хранилища
• Subversion. Установка и настройка. День второй — настройка Eclipse для работы с svn, создание проекта, проверка работоспособности. К этой заметке у меня есть замечание. На сколько я понял, автор предлагает размещать воркспейс эклипса в том каталоге, где будет вестись разработка, т.е. в докрут девелоперского сайта. С таким предложением я категорически несогласен — воркспейс должен лежать в домашней директории пользователя, иначе придется делать лишние телодвижения и поиметь возможность нарваться на решение различных проблем. А чтобы вести разработку в нужном нам каталоге, достаточно указать его при создании проекта — место размещения воркспейса и место разработки никак не связаны.
• Управление сторонними библиотеками в Subversion — небольшая заметка о внешних зависимостях, очень кратко: зачем это нужно и как это делать.

Кроме вышеперечисленных, в блоге есть еще несколько интересных постов, например, о переходе на Ubuntu.

Похожие записи

• Советы по фиксациям в SVN (0)
• Как слить изменения между ветками. Часть 2 (1)
• Как слить изменения между ветками. Часть 1 (1)
• Как и Зачем делать ветки? (3)
• Внешние зависимости (1)

А рассказать сегодня я хочу об еще одной неочевидной вещи Subversion-а — «внешних зависимостях».

«Внешние зависимости» — это способ включения в дерево своего проекта любые каталоги из других проектов и других хранилищ. Это несколько напоминает симлинки в юникс-лайк файловых системах. Т.е. в каком-либо каталоге проекта создается ссылка на другой каталог и при создании рабочей копии этого проекта (или апдейте существующей РК) вместо ссылки будет создана рабочая копия из того места, куда указывает эта ссылка.

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

Свойство, отвечающее за внешние зависимости, называется svn:externals. Для его установки можно воспользоваться командой svn propedit или пунктом «Properties» (если воспользоваться TortoiseSVN).

Чаще всего внешние зависимости используются для включения в проект различных библиотек. В качестве примера я покажу как включить в свой проект Zend Framework и Smarty. Подключать я предлагаю в отдельный каталог lib. Я предполагаю, что этот каталог уже находится в хранилище.

Вызвав контекстное меню каталога lib, выбираем пункт «Свойства». В открывшемся окне нажимаем на кнопку «Добавить»

Из списка свойств выбираем нужное нам свойство

и в области значения свойства вводим название каталога и адрес хранилища:

Zend http://framework.zend.com/svn/framework/tag/release-1.0.3/library/Zend
smarty http://smarty-php.googlecode.com/svn/tags/Smarty_2_6_18/libs

После этого жмем на кнопку «ОК»

После этого делаем commit, а за тем update. Вуаля! Наш каталог содержит ZF и smarty.

Хочу обратить внимание на адреса подключения библиотек — они указывают на конкретный релиз библиотеки. Это гарантирует стабильность работы, конечно по сравнению с веткой разработки. Можно было бы забирать библиотеки и из главной ветки, просто нужно дополнить путь номером правки — эффект получился бы такой же. Но указание в пути номера релиза гораздо удобней, на мой взгляд.

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

Если возникнет желание подробнее разобраться в теме этого поста, рекомендую прочитать раздел «Внешние зависимости» из 3-й главы мануала.

Похожие записи

• Как слить изменения между ветками. Часть 2 (1)
• Как слить изменения между ветками. Часть 1 (1)
• Как и Зачем делать ветки? (3)
• Советы по фиксациям в SVN (0)
• Снова про использование Subversion (0)

В начале я хочу дать немного теории, а потом покажу на примере как это делать.

Для копирования изменений служит команда merge. Принцип действия этой команды очень прост – сравнивается два состояния хранилища, и выявленные изменения вносит в рабочую копию. Вот этот момент (внесение изменений именно в рабочую копию) был первым моим открытием. До чтения документации я считал, что изменения вносятся сразу в хранилище. О второй неожиданности я расскажу подробнее.

Как большинство новичков, я предполагал, что для переноса изменений из одной ветки в другую, нужно в аргументах команды merge указать исходную ветку и приемную ветку. При чтении мануала я крайне удивился — оказывается, нужно сравнивать не текущие состояния сливаемых веток, а состояния исходной ветки с момента последнего слияния (или выделения отдельной ветки) и текущим состоянием (или любым другим прошлым). Это было настоящим открытием для меня! Так что, мой вам совет – читайте документацию, там бывает можно найти много интересного и полезного. (Глава из официального руководства, посвященная копированию изменений)

Классическим способом использования SVN, при котором может понадобится слияние, является вынесение в отдельную ветку разработки, потенциально опасной для стабильности кода в основной ветке. В этом случае создается отдельная ветка (о том, как это сделать я рассказывал в отдельной заметке), в которую копируется основная ветка. После чего разработчик (или группа разработчиков) независимо от остальных начинает кодить новый функционал. Остальные разработчики продолжают работать с основной веткой (или создают свои ветки для кодинга «опасных» участков). В случае применения такого способа разработки возникает опастность внесения настолько большого количества изменений в основную ветку и ветку «опасной» разработки, что объединить их потребует огромных усилий (или вообще будет невозможно). Чтобы этого не случилось, есть простое решение — с определенной периодичностью или при определенных событиях (например, внесение существенных изменений в основню ветку) сливать изменения основной ветки в ветку разработчика. Тогда финальное слияние нового функционала и основной ветки пройдет достаточно гладко и просто — ведь большая часть изменений основной ветки уже содержится в ветке разработчика.

На этом небольшой экскурс в теорию закончу и во второй части покажу на примере как выполнять слияние изменений в ветках.

Похожие записи

• Как слить изменения между ветками. Часть 2 (1)
• Как и Зачем делать ветки? (3)
• Внешние зависимости (1)
• Советы по фиксациям в SVN (0)
• Снова про использование Subversion (0)

Обновляемся отсюда

Похожие записи

• Советы по фиксациям в SVN (0)
• Снова про использование Subversion (0)
• Как слить изменения между ветками. Часть 2 (1)
• Как слить изменения между ветками. Часть 1 (1)
• Как и Зачем делать ветки? (3)

Приведу определение ветки из моей статьи:

Ветка (Branch) — это направление разработки, существующее независимо от других направлений, но имеющее общую с ними историю. Фактически представляет собой копию проекта (или его части) в определенный момент времени и совокупности фиксаций изменений. Чаще всего ветки используются для хранения различных релизов проекта. Кроме этого ветки могут применяться для изоляции группы правок, которые могут нарушить работоспособность всего кода.

Из определения вытекает ответ на вторую часть вопроса заголовка: ветки используются для создания независимых вариантов проекта с ведением собственной истории. Чтобы было понятнее, я опишу рекомендуемую разработчиками системы практику применения этой функции.

Основной процесс разработки обычно ведется в специальной ветке — trunk. Там разрабатывается новый функционал или переписывается код для уже реализованных функций проекта.

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

А теперь я покажу как создаются ветки. Команда для этого очень простая:
svn copy http://svn.example.com/repos/proj/trunk \
http://svn.example.com/repos/proj/branches/my-own-branch \
-m "Creating a private branch of /proj/trunk."
Т.е. создание ветки — это фактически копирование определенного каталога в новое место. Все очень просто.

Если пользоваться win-клиентом, то сделать ветку тоже не сложно:

1. Вызываете контекстное меню проводника и запускаете «браузер хранилища» (Repo-browser).
2. В репо-браузере выбираете ветку, от которой нужно «отпочковать» новую (чаще всего это будет ветка trunk), и в контекстном меню жмите на «Copy to...».
3. В появившемся окне вводите новое местоположение ветка (чаще всего ветки создаются в каталоге branches).
4. В следующем окне вводите комментарий. И вуаля — новая ветка готова!

Как вы видите, создать новую ветку очень просто. А их применение во многих случаях решает много проблем координации разработки.

Похожие записи

• Как слить изменения между ветками. Часть 2 (1)
• Как слить изменения между ветками. Часть 1 (1)
• Внешние зависимости (1)
• Советы по фиксациям в SVN (0)
• Снова про использование Subversion (0)

Анонс статьи на .hostinfo:

Одним из инструментов, применяемых разработчиками программного обеспечения, являются системы контроля версий исходного кода. В настоящее время существует несколько таких систем: CVS (наиболее известная и распространенная), Visual SourceSafe от Microsoft, StarTeam от Borland, Rational ClearCase от IBM. Кроме перечисленных продуктов есть ряд других, в том числе Subversion. Именно эта система является темой данной статьи. В ней приведены общие сведения, на примерах показан принцип работы с системой.

Со статьей можете ознакомиться тут

Похожие записи

• Советы по фиксациям в SVN (0)
• Снова про использование Subversion (0)
• Как слить изменения между ветками. Часть 2 (1)
• Как слить изменения между ветками. Часть 1 (1)
• Как и Зачем делать ветки? (3)