Pull to refresh

Comments 59

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

не поймёт — в топку.
т. е. статья не для новичков :) но если целью материала является передача знаний, не лишне приложить чуточку усилий для нормального восприятия этих знаний.
не сомневаюсь в полезности вашего поста, но на статью не катит совсем. хотя я рад, что есть люди, которым она полезна ;)
мда... непробиваемый аргумент :) заметьте, я не говорил, что пишу лучше вас, но я по крайней мере умею читать.
вы боитесь критики или уже считаете меня своим врагом???
вместо того, чтобы делать намеки наподобие "а сам...?", можете почитать статьи Зубинского в ko.itc.ua, замечательный автор, пишущий на замечательные темы. посмотрите, как тема дается у него.
да нет, критика вся в тему, я в общем понимаю, что это до некоторой степени драфт кровью сердца.

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

это я ещё даже не стал пока читать, что там за статьи у Зубинского :)
Исконно русское слово драфт... А за статью спасибо. Вовремя.
От лица минимум одного "не умеющего" - всё понял и сделал выводы. Честно )
Хорошая статья, спасибо. Хоть и работаю с свном уже давно, и многие вещи считаю практически естественными, но кое-что подчерпнул. Щас добавим вам "кармической силы" =)
На счет коммента к коммиту с разрозненными пунктами: предполагается, что к такого рода комментам следует относиться уничтожающим вниманием на среднем и позднем этапах работы, так? Ведь на этапе дебюта можно, в самом деле, наворотить много делов и не факт, что они будет тесно связаны.
на третьем этапе строгое "нет"

на втором — публичное унижение и оставление без завтрака
Спасибо. Почерпнул немного полезного. Есть рекомендации которые помогут в дальнейшем качественно хорошо работать в команде.
По diff перед коммитом. Ну так для себя чисто открыл colordiff и команда - "svn diff | colordiff | less -SR" - это вообще красота!!!

Про переименование файла - вот тут не согласен с двумя коммитами, вполне возможно обойтись и одним - просто надо правильно переименовывать (svn move), а потом правим этот файл и коммитим. SVN в этом сдучае дифф между версиями покажет нормальный.

Ну и в эндшпиле еще есть хорошая практика тэгов. То есть перед RC, или релизом версии (точнее во время) создается тэг - то есть непосредственно то что лежит на продакшене, что бы можно было с точностью взять код продакшена и попробовать воспроизвести на нём тот баг, который происходит.
в файле ~/.subversion/config можно определить diff-cmd = colordiff
ну я уже давно сделал алиас, но надо будет попробовать законфигурять так как вы говорите.
алиас тем плох — что ломает рефлексы по набиранию svn di
лучше конфигурить старые команды, чем учить новые
svn diff | colordiff | less -SR
Вообще супер !
Согласен про один коммит. Вообще в статье много утверждений, не подкреплённых аргументами.
Опыт подразумевает, что вы пытались делать иначе и наступили на грабли, но вместо того, чтобы их описать, вы предлагаете просто делать два коммита. Почему читатель должен верить вам на слово?
«Смысл этого требования состоит в игре на благо будущего. Соблюдая его, можно быть уверенным, тот или иной коммит в потоке либо безопасен (например, фикс документации), либо может быть свободно откачен с уверенностью, что откатилось в точности одно логическое изменения. Это бесценное свойство при бинарном поиске ошибок. Более того, очевидно, что логичные изменения гораздо проще отсматривать в процессе код-ревью.»
бывают ситуации, когда переименование файла и изменения в нём же — это одно логическое изменение
если я правильно помню, на этом глючит svnlog. если не так, то нужно исправить текст.
>>Вопросы, пожелания, предложения?

Поясните хотя бы вначале сленговые слова, для того, чтобы непосвященным было понятнее раз, для того, чтобы выглядело по-человечески, а не перепиской в аське два. =)

А использование шахматных терминов порадовало :).

Ну и конечно, у меня сильное ощущение, что текст можно было бы сократить минимум в два раза, если бы поперечитывали и подредактировали.
это вобщем-то не сленговые слова, а команды и понятия из Subversion. Ежели вы пользуетесь SVN-ом, вам эти слова знакомы, а если вы только собираетесь пользоваться, то можно/нужно почитать что-то другое, перед этой статьей.
http://google.com/search?hl=ru&q=%D1%87%…
>> Мы молчим про пустые журнальные сообщения — это вообще худшее что может быть. Это допустимо только для совершенно далеких от программирования сотрудников (типа дизайнеров), которые на этот ваш сабвершен с трудом вообще согласились.

На эту тему удивил лог acts_as_state_machine, в котором вообще почти все коменты к коммитам пустые: http://codenotifier.com/projects/15
Мож у чувака какой-то стоит ловкий просмотрщик лога, который диффы сразу кажет - при том объеме кода комменты может и излишни.
По поводу хранения кусков кода в закоментированном состоянии есть контр пример. Часто бывает, что какая-то функциональность не вынесена в отдельную структурную единицу (функцию или т.п.), а исключить её из основного кода надо. При этом точно известно, что она понадобится в будующем (ну или возможно понадобится). Если эту часть кода удалить, считая что в репозитории она всёравно есть, то возникнут две проблемы, когда её надо будет вернуть:
1. никто не вспомнит в какой ревизии оно отсюда исчезло (по diff-ам и blame-ам можно очдолго ползать, если уже много накоммитили)
2. даже если удастся достать этот кусок из репозитория, он может быть уже протухшим (изменились имена глобальных переменных и прочие последствия глобальных рефакторингов)

Поэтому в своей практике я вполне допускаю закоментированные куски кода, при условии, что "глобальные рефакторинги" на них распространяются. Да, это не гарантирует работоспособность (всётаки код не исполняется и никак проверить нельзя), но при достаточной аккуратности даёт больше чем удаление и надежда на репозиторий.
Гм. А как рефакторинги могут распространяться на закомментированые куски кода? Я думал, sed-ом уже никто не рефакторит :). Или какие-то IDE-шки лазят в комментарии?
я может вас огорчу, но в мире существуют языки для которых автоматический рефакторинг не настолько хорош, как хотелось бы
когда пишешь на них приходится рефакторить "sed-ом", а иногда... вручную
Наверное, это... php? :)
Впрочем, понятно. Дествительно. Просто ява сильно расслабляет в этом плане :).
Зря вы так про дизайнеров, не так там всё запущено. Другое дело, что часто правки дизайнерские описывать дольше, чем делать. в этом случае мы просто указываем, что было поправлено и указываем ID таска, где задача расписана более подробно, зачастую со скринами того, что надо сделать.
Какая-то СС'овская терминология у Вас :)) А вообще все можно упростить если на полную использовать merge.
что именно можно упростить, если на полную использовать мердж? и определите понятие "на полную". и скажите, в какой системе.
Проще сказать как делаем мы (как я понимаю, это классический подход). Система - subversion 1.5 (beta, с поддержкой merge tracking).
1) есть транк (основная ветка), куда делаюттся аккуратные, протестированные, логически целостные и задокумментированные коммиты. Сюда также коммитятся все багфиксы.
2) Для каждой мажорной фичи или версии создается бранч, куда можно коммитить грязно и беспорядочно, для ускорения процесса. Здесь допускаются битые ревизии. 3) Есть branches/stable, куда после тестирования тестером, перед рилизом, мерджатся все изменения в транке. 4) Бранчи мерджатся предварительно в транк.
"На полную" - как раз, используя svn 1.5/(1.4.99). У collabnet есть блог (ссылки не могу прилагать), где хорошо описываются недостатки ручного мерджа (да это просто ад), и то как он будет работать в 1.5.
Ну вы герои, использовать нерелизнутый 1.5, который судя по тракеру ещё достаточно сырой. Что ещё тут можно сказать.
Пока что ни одного нарицания, ни к серверу(кроме необходимости переконвертить репозитории из BDB в FSFS (BDB не поддерживается, имейте ввиду когда будете создавать новый репо)), ни к соответствующему TortoiseSVN (много хороших фичей помимо мерджинга, включая поддержку висты)
Бранч для каждой мажорной фичи? Не моноговато ли? Скажите, сколько у вас на текущий момент бранчей?
мажорная фича - пожалуй неверно сказано. Речь идет о переработке коры, любой рефакторинг и тд, все что не подлежит постоянному коммиту в транк и не является багфиксом. В данный момент всего одна, над которой идет работа. В новом TortoiseSVN, кстати, мердж минорных изменений в параллельной ветке (trunk->stable) отличается от мерджа из форкнутой(фичевой) ветки.
Если бы понял что-то, то наверно было бы очень интересно )))
Спасибо, хорошая статья. От себя добавлю, что полезно в лог коммита писать номер таска в баг(/таск)трекере.

И наверное вам надо было в начале статьи поставить ссылку на какую-нибудь вводную статью "Что такое контроль версий и с чем его едят" :)
Не понятно, почему вы не написали, что trac с subversion особенно хорош с trac'овским hook'ом на post-commit. В этом случае появляется возможность закрывать задачи и писать в комментарии к задачам с помощью log message.
А не помнит ли кто-нибудь линк на статью про git на хабре? Вообще было бы интересно почитать нечто подобное про git, ибо есть нюансы.

И еще автору: мне кажется было бы мега полезно привести примеры правильных и неправильных коммитов (особенно description-ов).
Ага Git интересная штука. В некоторых случаях (когда доходит до branch-merge) удобнее чем Subversion.
UFO just landed and posted this here
Cпасибо за статью, воспринимается легко и познавательно. По поводу предложений, хотелось бы в таком же стиле статью про управление ветками (branches), про то как правильно создавать, коммитить, обьединять и разрешать конфликты.
Насчёт хорошей документируемости коммитов.

Нельзя не упомянуть, как в контексте исследования старого (legacy) кода,
так и в качестве наказаний для молчунов (пустые логи) и лентяев (лог просто "fixed") о возможности править svn:log:

svn pe svn:log -r XXX --revprop

В первом случае позволяет удобным образом хранить замечания о давних (и невнятных) коммитах, во втором... заменить битьё по рукам полезным деянием.
Большое спасибо. Жму руку, тащу в корпоративную вики (копирайты сохраняю, конечно :).
Корпоративная вики, а вы случайно Trac не пользуетесь? Там есть встроенная вики. Мы на данный момент используем её.
Или у вас какой-то другой движок?
Trac не пользуемся. Используем MoinMoin, http://www.google.ru/search?q=moinmoin, рекомендую от всей души. Но в виках главное — вовсе не движок, главное — контент, а движок — дело вкуса и удобства. :)
особо нового ничего для себя не вынес, но спасибо!

зы особенно хорошо с результатами коммитов IJ Idea умеет работать - сама проверит обновления, покажет чейджлог, предупредит перед началом изменения файла, что он уже устарел.
спасибо, полезная заметка. еще чуть упорядочить текст и немного примеров, поясняющих каждый абзац и получится отличная статья.
Некоторые замечания по названиям фаз разработки (дебют, миттельшпиль и эндшпиль)
Мне как-то привычнее общепринятые термины feature-freeze, code-freeze, system-test-freeze,
на которых всё меньше вносится крупных изменений в код и добиваются большей стабильности, всё жестче ограничения на коммиты.
Sign up to leave a comment.

Articles