Comments 60
Однозначно хорошая статья, побольше бы таких.
Даже не выделишь из пунктов самый важный — все одинаково важны.
а я бы все таки выделил:
перед тем как фиксировать, надо забрать последнюю версию, протестировать и только потом выкладывать. А то находятся умники, у которых все билдится, выкладывают, а потом все падает
по поводу svn update перед коммитом — изменения в результате могут превратиться в жуткую кашу из своих и чужих правок. но видимо тут ничего не поделаешь, проблема на концептуальном уровне.
дело не только в этом. бывают случаи когда конфликта нет, а после фиксации все падает.
простой пример:
был когда то Класс1. Пользователь использует его методы, фиксирует свои данные.А уже в том классе нет некоторых методов
Согласен. Но апдейт перед комитом тем более необходим, чтобы предотвратить такие ситуации.
возможно стоит задуматься над тем почему обновление перед фиксацией приводит к жуткой каше? я пытаюсь найти в своем опыте соответствующие примеры и вспоминаю только один — когда два разработчика одновременно работают над одним участком кода. это неправильно
Это, конечно, не идеальный вариант, но вполне встречающийся в реальной жизни (например, надо горсть констант добавить в общий .hpp).
В общем, от ситуации зависит. Мы (человек пять) года три назад вообще сначала коммит между собой согласовывали, потом делали чекаут в отдельную папку, потом мержили её со своими изменениями, и уж только потом коммитили обратно. После этого кто-нибудь другой чекаутил себе и проверял, что всё собирается.

Ну потом-то мы научились срезать углы в этих процессах… Но перерывов на чай стало меньше.
«вполне встречающийся в реальной жизни» — это не оправдание некорректности подхода.

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

я пытаюсь сказать — что каша после коммита — это звоночек, который какбе говорит нам «эй, ребята, задумайтесь, правильно ли вы используете контроль версий, или может вы неправильно разбиваете задачи?»
согласен — запутал. правильнее говорить — каша после апдейта перед коммитом.
я имел ввиду следующую ситуацию.
1. Разработчик A вносит изменения в какой-нибудь файл.
2. Разработчик B вносит изменения в то же место и в тот же файл что и разработчик A.
3. A делает обновление рабочей копии и, затем успешно фиксирует изменения.
4. B делает обновление рабочей копии, и, ОМГ! получает кучу конфликтов.
С какой стати? Чужие правки в список изменений не попадают.
Что Вы имеете в виду?

По поводу «каши» согласен: я прокоментировал частный случай такой «каши» — конфликты.
Я имею в виду, что из комментария evilbloodydemon складывается впечатление, что те чужие изменения, которые я забираю при апдейте, потом будут видны как мои правки.

Но это же не так. В список изменений попадут только мои правки.

Так что апдейт перед коммитом — обязательная процедура. Иначе вполне может сложиться такая ситуация, что у каждого разработчика код рабочий, а в репозитории — нет.
Теперь я понял.

Просто я решил, что Ваш ответ относится к моему комментарию на реплику evilbloodydemon. Поэтому решил уточнить, что имелось в виду
я уже открыл меркуриал давно. я имел в виду отсутствие в svn фиксации собственных изменений перед апдейтом. то есть проблема в том, что мои изменения логически завершены, но я не могу их закоммитить, потому что кто-то закоммитился раньше и мне нужно поапдейтиться. и в случае конфликта придется исправлять его при несохраненных изменениях. что, мягко говоря, неудобно.
а в меркуриале этот случай разбит на две операции — коммит (вне зависимости ни от чего моя работа уже сохранена) и мердж.
Работайте в отдельной ветке и фиксируйте когда угодно.
командой svn status можно проверить, какие файлы вошли в commit — собственно это (вместе с diff) нужно делать чтобы проверить, что фиксируется.

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

Так что я соглашусь с автором(ами) и предпочту делать svn up
Да, действительно — оказывается svn дает закоммититься если рабочая копия старее репозитария, но конфликтов commit не создает. Все-таки Subversion чем-то продвинутая система, а чем-то — CVS…
Нашел очень много общего с нашими внутри-конторовыми стандартами использования svn :) (10 из 12 пунктов совпадают)
Все достаточно очевидно и всплывает практически сразу при активном использовании svn вместе с другими разработчиками.
Правила действительно очевидные и наверняка во многих командах эти правила в том или ином виде есть. Но я думаю, что эта статья будет полезна тем, у кого либо мало опыта работы с системами контроля версий, либо не было опыта работы в команде, имеющей формализованные правила работы с SVN.
Отличная статья, только не понятно название.
Все рекомендации, ИМХО, имеют отношение к групповой разработке
с использованием почти любой системы контроля версий, а не именно SVN.
Работа с VSS(не к столу будь сказано :) или с ClearCase также требует
дисциплины и ответственности…
Оригинал статьи — некий свод правил проекта T2. А в своей работе они используют SVN. Отсюда и название статьи.
Я понял. Но стоило-бы, ИМХО, в предисловии к переводу добавить, что статья имеет отношение к групповой разработке с использованием любой системы контроля версий.
В любом случае спасибо :)))
Скажите, а вы и правда так и говорите — «фиксировать изменения в хранилище»? Не «коммитить» и не «класть»?

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

Кстати, те же самые термины используются в официальном переводе руководства по SVN.

PS: обычно я говорю «закомитить в репозиторий», а также «пофиксить баги», «отдебажить» и много других страшных слов :)
Долго медитировал над словом «фиксация», признаюсь, впервые его встречаю в таком контексте, всегда было «закоммитить». Это официальный русскоязычный термин?
Из личного опыта разработки в большом коллективе:

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

— за каждый участок кода ( минимальная единица — файл ) должен быть ответственный. Именно он проверяет правильность кода после того, как туда положили все изменения, и до того, как его выдадут в отдел тестирования. И чтобы не отмазывался «это не моё изменение».

— комментарии к изменениям это здорово, но нельзя переусердствовать. В одной из компаний видел методологию разработки, когда каждое изменения оборачивалось в комментарии «begin/end commit 'name' date», старый код комментировался, новый писался. Из-за чего размер некоторых файлов доходил до 2-3 тысяч строк, состоящих из одних комментариев к изменениям. Лучше не писать комментарий вида «я поменял здесь это на это», а писать комментарий «здесь должно быть вот так, потому что...». Историю изменений всегда можно посмотреть в хранилище, для того оно и служит.
Спасибо за интересное и полезное дополнение.

По поводу комментариев полностью согласен. Ваш пример показывает полное непонимание людьми принципов работы с системой контроля версий, т.к. они вручную делали то, для чего СКВ и предназначена
Про тестирование. Проводить комплексное тестирование перед коммитом очень неправильный выбор, это занимает очень много времени. В идеале всё должно покрываться несколькими уровнями тестов: юнит-тесты, автотесты. И коммитить можно при успешном выполнении локальных юнит-тестов компонента. Естественно, юнит-тесты должны также проверять межкомпонентные связи.

Про ответственного. Тут согласен. Необходим какой-нибудь инструмент коллективного обсуждения коммитов, нечто вроде Code Collaborator. Коммит принимается в VCS исключительно после положительного завершения ревью. Эта схема может показаться медленной и затратной, но на практике всё не так страшно. Большинство разработчиков быстро втягиваются в процесс, а бонусом является бо́льший кодовый кругозор каждого разработчика.

Про комментарии. В комментарии к коммиту должен стоять номер ревью в системе обсуждения изменений, зависимые баги и краткое описание изменений. Этого вполне достаточно. Естественно, все средства работы (багзилла, коллаборатор) должны быть интегрированы с VCS.
Вот для того, чтобы тестирование не занимало много времени, тесты должны быть автоматические. Например, у меня большинство тестов — это проверка работоспособности системы целиком (от логического начала и до конца), в процессе которого обязательно должна использоваться новая/исправленная функция. Во-первых, сама функция тестируется, во-вторых, тестируется работоспособность приложения с этой функцией. И времени занимает секунд 10-15.

Про комментарии к commit согласен, но я имел ввиду комментарии в коде :)
Не так всё просто, вот у нас, например, один из проектов собирался часа три как минимум. А полный сеанс автотестов занимал часов десять. Разработчик, конечно, проверяет, что у него на машине оно собралось, но делать это в автоматическом режиме самоубийственно.
наличие ответственного — довольно странное требование, коллективное владение кодом на практике лучше
Довольно полезное, чтобы предотвратить заявление «я это не ломал», «само сломалось», «это никто не трогал» и т.д.

Если что-то не работает, то по умолчанию считается, что ответственен тот, в чьём коде произошла ошибка. Не важно при этом, кто его изменял на самом деле (потому что ответственный все эти изменения обязан отслеживать).

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

Личное владение кодом тормозит изменения и порождает бардак
Никто не мешает коммитить код — работа идёт как и ранее (общей review во время коммита предлагал Cancel).

А код может сломаться не только сам по себе, но и из-за изменений во внешних условиях — изменения в базе данных, немного другие входные данные, и т.д.
У нас раньше тому кто ломал транк ставили на стол резинового петуха. переставить его нельзя пока кто-то другой не поломает :)
:)

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

ИМХО, коммитить надо как только появляется возможность написать осмысленный комментарий.

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

А /trunc он все равно время от времени ломается. А вот найти место поломки среди массового коммита, очень бывает тяжко.

ИМХО, идеально коммитить каждый раз после зеленой полосы в тесте :)
Комитить нужно задачу. Какой смысл комитить наполовину сделаную задачу, пусть даже код дает зеленую полосу.

Если комиты получаются слишком большими, то нужно разбивать задачу на несколько более мелких.
Существует 2 общеупотребимых модели разработки:
1) стабильный trunk — все сидят в своих ветках, потом главный мерджит в trunk, когда результат мерджа ветки компилируется.
2) живой trunk — все коммитят в trunk не боясь нудности согласований, те, кому нужна стабильность на время разработки — делают себе отдельную ветку, потом самостоятельно коммитят в trunk

Ни в одной не возникает проблем «массового коммита».
Можно просто возвращаться по коммиту назад и искать где тесты перестали работать.

Собственно автоматические системы вроде buildbot так и делают (вернее наоборот — гоняют тесты на каждый commit, вытягивая изменения по одному коммиту)
Единственное замечание автору — нужно в каждой переводной статье оставлять ссылку на оригинал.
А так все отлично, спасибо за находку.
Only those users with full accounts are able to leave comments. Log in, please.