Comments 60
Однозначно хорошая статья, побольше бы таких.
Даже не выделишь из пунктов самый важный — все одинаково важны.
Даже не выделишь из пунктов самый важный — все одинаково важны.
по поводу svn update перед коммитом — изменения в результате могут превратиться в жуткую кашу из своих и чужих правок. но видимо тут ничего не поделаешь, проблема на концептуальном уровне.
svn в любом случае не даст зафиксировать конфликты
возможно стоит задуматься над тем почему обновление перед фиксацией приводит к жуткой каше? я пытаюсь найти в своем опыте соответствующие примеры и вспоминаю только один — когда два разработчика одновременно работают над одним участком кода. это неправильно
Это, конечно, не идеальный вариант, но вполне встречающийся в реальной жизни (например, надо горсть констант добавить в общий .hpp).
В общем, от ситуации зависит. Мы (человек пять) года три назад вообще сначала коммит между собой согласовывали, потом делали чекаут в отдельную папку, потом мержили её со своими изменениями, и уж только потом коммитили обратно. После этого кто-нибудь другой чекаутил себе и проверял, что всё собирается.
Ну потом-то мы научились срезать углы в этих процессах… Но перерывов на чай стало меньше.
В общем, от ситуации зависит. Мы (человек пять) года три назад вообще сначала коммит между собой согласовывали, потом делали чекаут в отдельную папку, потом мержили её со своими изменениями, и уж только потом коммитили обратно. После этого кто-нибудь другой чекаутил себе и проверял, что всё собирается.
Ну потом-то мы научились срезать углы в этих процессах… Но перерывов на чай стало меньше.
«вполне встречающийся в реальной жизни» — это не оправдание некорректности подхода.
у меня были ситуации, когда после коммита получалась каша. но после разбора полетов оказывалось что либо кто-то неправильно работал с системой контроля версий, либо два человека делали одну и ту же работу. оба варианта — зло.
я пытаюсь сказать — что каша после коммита — это звоночек, который какбе говорит нам «эй, ребята, задумайтесь, правильно ли вы используете контроль версий, или может вы неправильно разбиваете задачи?»
у меня были ситуации, когда после коммита получалась каша. но после разбора полетов оказывалось что либо кто-то неправильно работал с системой контроля версий, либо два человека делали одну и ту же работу. оба варианта — зло.
я пытаюсь сказать — что каша после коммита — это звоночек, который какбе говорит нам «эй, ребята, задумайтесь, правильно ли вы используете контроль версий, или может вы неправильно разбиваете задачи?»
Не понимаю, как может быть каша после коммита?
согласен — запутал. правильнее говорить — каша после апдейта перед коммитом.
я имел ввиду следующую ситуацию.
1. Разработчик A вносит изменения в какой-нибудь файл.
2. Разработчик B вносит изменения в то же место и в тот же файл что и разработчик A.
3. A делает обновление рабочей копии и, затем успешно фиксирует изменения.
4. B делает обновление рабочей копии, и, ОМГ! получает кучу конфликтов.
я имел ввиду следующую ситуацию.
1. Разработчик A вносит изменения в какой-нибудь файл.
2. Разработчик B вносит изменения в то же место и в тот же файл что и разработчик A.
3. A делает обновление рабочей копии и, затем успешно фиксирует изменения.
4. B делает обновление рабочей копии, и, ОМГ! получает кучу конфликтов.
С какой стати? Чужие правки в список изменений не попадают.
Что Вы имеете в виду?
По поводу «каши» согласен: я прокоментировал частный случай такой «каши» — конфликты.
По поводу «каши» согласен: я прокоментировал частный случай такой «каши» — конфликты.
Я имею в виду, что из комментария evilbloodydemon складывается впечатление, что те чужие изменения, которые я забираю при апдейте, потом будут видны как мои правки.
Но это же не так. В список изменений попадут только мои правки.
Так что апдейт перед коммитом — обязательная процедура. Иначе вполне может сложиться такая ситуация, что у каждого разработчика код рабочий, а в репозитории — нет.
Но это же не так. В список изменений попадут только мои правки.
Так что апдейт перед коммитом — обязательная процедура. Иначе вполне может сложиться такая ситуация, что у каждого разработчика код рабочий, а в репозитории — нет.
А вы откройте для себя распределённые системы контроля версий. Тут можно почитать живым русским текстом — Mercurial: введение в распределённые системы контроля версий. В конце статьи есть ссылка на следующую часть.
я уже открыл меркуриал давно. я имел в виду отсутствие в svn фиксации собственных изменений перед апдейтом. то есть проблема в том, что мои изменения логически завершены, но я не могу их закоммитить, потому что кто-то закоммитился раньше и мне нужно поапдейтиться. и в случае конфликта придется исправлять его при несохраненных изменениях. что, мягко говоря, неудобно.
а в меркуриале этот случай разбит на две операции — коммит (вне зависимости ни от чего моя работа уже сохранена) и мердж.
а в меркуриале этот случай разбит на две операции — коммит (вне зависимости ни от чего моя работа уже сохранена) и мердж.
на самом деле автор статьи путает 'svn status' и 'svn up'
Поясните
командой svn status можно проверить, какие файлы вошли в commit — собственно это (вместе с diff) нужно делать чтобы проверить, что фиксируется.
Далее SVN просто не даст закоммитить при наличии изменений в хранилище, и тогда уже портребуется update и исправление конфликтов
Далее SVN просто не даст закоммитить при наличии изменений в хранилище, и тогда уже портребуется update и исправление конфликтов
Нашел очень много общего с нашими внутри-конторовыми стандартами использования svn :) (10 из 12 пунктов совпадают)
Все достаточно очевидно и всплывает практически сразу при активном использовании svn вместе с другими разработчиками.
Все достаточно очевидно и всплывает практически сразу при активном использовании svn вместе с другими разработчиками.
Отличная статья, только не понятно название.
Все рекомендации, ИМХО, имеют отношение к групповой разработке
с использованием почти любой системы контроля версий, а не именно SVN.
Работа с VSS(не к столу будь сказано :) или с ClearCase также требует
дисциплины и ответственности…
Все рекомендации, ИМХО, имеют отношение к групповой разработке
с использованием почти любой системы контроля версий, а не именно SVN.
Работа с VSS(не к столу будь сказано :) или с ClearCase также требует
дисциплины и ответственности…
Скажите, а вы и правда так и говорите — «фиксировать изменения в хранилище»? Не «коммитить» и не «класть»?
Сама статья очень разумная и хорошая, правда приведённые правила достаточно естественны.
Сама статья очень разумная и хорошая, правда приведённые правила достаточно естественны.
В каждой предметной области есть термины и есть жаргонизмы. В переводе статьи лично я считаю правильнее использовать официальные термины, нежели какие-либо жаргонные словечки.
Кстати, те же самые термины используются в официальном переводе руководства по SVN.
PS: обычно я говорю «закомитить в репозиторий», а также «пофиксить баги», «отдебажить» и много других страшных слов :)
Кстати, те же самые термины используются в официальном переводе руководства по SVN.
PS: обычно я говорю «закомитить в репозиторий», а также «пофиксить баги», «отдебажить» и много других страшных слов :)
да блин вроде как прописные истины, главное не забывать о них
Долго медитировал над словом «фиксация», признаюсь, впервые его встречаю в таком контексте, всегда было «закоммитить». Это официальный русскоязычный термин?
Из личного опыта разработки в большом коллективе:
— тестирования необходимо комплексное (желательно — всё приложение, так как сломать можно что угодно), но быстрое. Таким образом, тестировать надо автоматическими тестами. Перед тем, как положить код в хранилище, надо провести как локальные тесты (на файл, который поменялся), так и комплексное, что не сломалась работа приложения.
— за каждый участок кода ( минимальная единица — файл ) должен быть ответственный. Именно он проверяет правильность кода после того, как туда положили все изменения, и до того, как его выдадут в отдел тестирования. И чтобы не отмазывался «это не моё изменение».
— комментарии к изменениям это здорово, но нельзя переусердствовать. В одной из компаний видел методологию разработки, когда каждое изменения оборачивалось в комментарии «begin/end commit 'name' date», старый код комментировался, новый писался. Из-за чего размер некоторых файлов доходил до 2-3 тысяч строк, состоящих из одних комментариев к изменениям. Лучше не писать комментарий вида «я поменял здесь это на это», а писать комментарий «здесь должно быть вот так, потому что...». Историю изменений всегда можно посмотреть в хранилище, для того оно и служит.
— тестирования необходимо комплексное (желательно — всё приложение, так как сломать можно что угодно), но быстрое. Таким образом, тестировать надо автоматическими тестами. Перед тем, как положить код в хранилище, надо провести как локальные тесты (на файл, который поменялся), так и комплексное, что не сломалась работа приложения.
— за каждый участок кода ( минимальная единица — файл ) должен быть ответственный. Именно он проверяет правильность кода после того, как туда положили все изменения, и до того, как его выдадут в отдел тестирования. И чтобы не отмазывался «это не моё изменение».
— комментарии к изменениям это здорово, но нельзя переусердствовать. В одной из компаний видел методологию разработки, когда каждое изменения оборачивалось в комментарии «begin/end commit 'name' date», старый код комментировался, новый писался. Из-за чего размер некоторых файлов доходил до 2-3 тысяч строк, состоящих из одних комментариев к изменениям. Лучше не писать комментарий вида «я поменял здесь это на это», а писать комментарий «здесь должно быть вот так, потому что...». Историю изменений всегда можно посмотреть в хранилище, для того оно и служит.
Спасибо за интересное и полезное дополнение.
По поводу комментариев полностью согласен. Ваш пример показывает полное непонимание людьми принципов работы с системой контроля версий, т.к. они вручную делали то, для чего СКВ и предназначена
По поводу комментариев полностью согласен. Ваш пример показывает полное непонимание людьми принципов работы с системой контроля версий, т.к. они вручную делали то, для чего СКВ и предназначена
Про тестирование. Проводить комплексное тестирование перед коммитом очень неправильный выбор, это занимает очень много времени. В идеале всё должно покрываться несколькими уровнями тестов: юнит-тесты, автотесты. И коммитить можно при успешном выполнении локальных юнит-тестов компонента. Естественно, юнит-тесты должны также проверять межкомпонентные связи.
Про ответственного. Тут согласен. Необходим какой-нибудь инструмент коллективного обсуждения коммитов, нечто вроде Code Collaborator. Коммит принимается в VCS исключительно после положительного завершения ревью. Эта схема может показаться медленной и затратной, но на практике всё не так страшно. Большинство разработчиков быстро втягиваются в процесс, а бонусом является бо́льший кодовый кругозор каждого разработчика.
Про комментарии. В комментарии к коммиту должен стоять номер ревью в системе обсуждения изменений, зависимые баги и краткое описание изменений. Этого вполне достаточно. Естественно, все средства работы (багзилла, коллаборатор) должны быть интегрированы с VCS.
Про ответственного. Тут согласен. Необходим какой-нибудь инструмент коллективного обсуждения коммитов, нечто вроде Code Collaborator. Коммит принимается в VCS исключительно после положительного завершения ревью. Эта схема может показаться медленной и затратной, но на практике всё не так страшно. Большинство разработчиков быстро втягиваются в процесс, а бонусом является бо́льший кодовый кругозор каждого разработчика.
Про комментарии. В комментарии к коммиту должен стоять номер ревью в системе обсуждения изменений, зависимые баги и краткое описание изменений. Этого вполне достаточно. Естественно, все средства работы (багзилла, коллаборатор) должны быть интегрированы с VCS.
Вот для того, чтобы тестирование не занимало много времени, тесты должны быть автоматические. Например, у меня большинство тестов — это проверка работоспособности системы целиком (от логического начала и до конца), в процессе которого обязательно должна использоваться новая/исправленная функция. Во-первых, сама функция тестируется, во-вторых, тестируется работоспособность приложения с этой функцией. И времени занимает секунд 10-15.
Про комментарии к commit согласен, но я имел ввиду комментарии в коде :)
Про комментарии к commit согласен, но я имел ввиду комментарии в коде :)
наличие ответственного — довольно странное требование, коллективное владение кодом на практике лучше
Довольно полезное, чтобы предотвратить заявление «я это не ломал», «само сломалось», «это никто не трогал» и т.д.
Если что-то не работает, то по умолчанию считается, что ответственен тот, в чьём коде произошла ошибка. Не важно при этом, кто его изменял на самом деле (потому что ответственный все эти изменения обязан отслеживать).
Иначе получается ситуация с ничейным кодом. Вроде у всего есть автор, а в целом никто ни за что не отвечает.
Если что-то не работает, то по умолчанию считается, что ответственен тот, в чьём коде произошла ошибка. Не важно при этом, кто его изменял на самом деле (потому что ответственный все эти изменения обязан отслеживать).
Иначе получается ситуация с ничейным кодом. Вроде у всего есть автор, а в целом никто ни за что не отвечает.
У нас раньше тому кто ломал транк ставили на стол резинового петуха. переставить его нельзя пока кто-то другой не поломает :)
Очевидные вещи, разве что последний пункт…
Спасибо за статью!
Есть разные фазы проекта, со своими правилами на каждой.
ИМХО, коммитить надо как только появляется возможность написать осмысленный комментарий.
А то потом появляются коммиты с комментарием с десятком пунктов, и с парой изменений, о которых разработчик забыл сообщить. И ищи если что потом из-за чего где поломалось.
А /trunc он все равно время от времени ломается. А вот найти место поломки среди массового коммита, очень бывает тяжко.
ИМХО, идеально коммитить каждый раз после зеленой полосы в тесте :)
ИМХО, коммитить надо как только появляется возможность написать осмысленный комментарий.
А то потом появляются коммиты с комментарием с десятком пунктов, и с парой изменений, о которых разработчик забыл сообщить. И ищи если что потом из-за чего где поломалось.
А /trunc он все равно время от времени ломается. А вот найти место поломки среди массового коммита, очень бывает тяжко.
ИМХО, идеально коммитить каждый раз после зеленой полосы в тесте :)
Комитить нужно задачу. Какой смысл комитить наполовину сделаную задачу, пусть даже код дает зеленую полосу.
Если комиты получаются слишком большими, то нужно разбивать задачу на несколько более мелких.
Если комиты получаются слишком большими, то нужно разбивать задачу на несколько более мелких.
Существует 2 общеупотребимых модели разработки:
1) стабильный trunk — все сидят в своих ветках, потом главный мерджит в trunk, когда результат мерджа ветки компилируется.
2) живой trunk — все коммитят в trunk не боясь нудности согласований, те, кому нужна стабильность на время разработки — делают себе отдельную ветку, потом самостоятельно коммитят в trunk
Ни в одной не возникает проблем «массового коммита».
1) стабильный trunk — все сидят в своих ветках, потом главный мерджит в trunk, когда результат мерджа ветки компилируется.
2) живой trunk — все коммитят в trunk не боясь нудности согласований, те, кому нужна стабильность на время разработки — делают себе отдельную ветку, потом самостоятельно коммитят в trunk
Ни в одной не возникает проблем «массового коммита».
Можно просто возвращаться по коммиту назад и искать где тесты перестали работать.
Собственно автоматические системы вроде buildbot так и делают (вернее наоборот — гоняют тесты на каждый commit, вытягивая изменения по одному коммиту)
Собственно автоматические системы вроде buildbot так и делают (вернее наоборот — гоняют тесты на каждый commit, вытягивая изменения по одному коммиту)
Единственное замечание автору — нужно в каждой переводной статье оставлять ссылку на оригинал.
А так все отлично, спасибо за находку.
А так все отлично, спасибо за находку.
Sign up to leave a comment.
Советы по фиксациям в SVN