Comments 59
кат поставьте ;)
0
Замечания по подаче материала:
В заголовке можно обойтись без слов "чеклист" и "коммит".
Слишком сумбурно, можно добавить хотя бы вступление. человек, который умеет грамотно работать с скв, обойдется без этой статьи, не умеющий, скорее всего, ничего не поймет в вашем изложении
В заголовке можно обойтись без слов "чеклист" и "коммит".
Слишком сумбурно, можно добавить хотя бы вступление. человек, который умеет грамотно работать с скв, обойдется без этой статьи, не умеющий, скорее всего, ничего не поймет в вашем изложении
+2
в общем, статья может и полезная, но вы явно не имеете опыта составления научно-познавательных материалов. создается немного впечатление, что она быстро писалась только для того, чтобы вконце пропиарить свои вакансии
0
ну это безусловно некоторый драфт
но имхо, такое снисходительное "не умеющий ничего не поймёт" лишнее. всё же если уж человек пришёл тут к нам в индустрию пусть не рассказывает, что маску сварщика на улице нашел.
не поймёт в топку.
но имхо, такое снисходительное "не умеющий ничего не поймёт" лишнее. всё же если уж человек пришёл тут к нам в индустрию пусть не рассказывает, что маску сварщика на улице нашел.
не поймёт в топку.
+4
т. е. статья не для новичков :) но если целью материала является передача знаний, не лишне приложить чуточку усилий для нормального восприятия этих знаний.
не сомневаюсь в полезности вашего поста, но на статью не катит совсем. хотя я рад, что есть люди, которым она полезна ;)
не сомневаюсь в полезности вашего поста, но на статью не катит совсем. хотя я рад, что есть люди, которым она полезна ;)
0
0
мда... непробиваемый аргумент :) заметьте, я не говорил, что пишу лучше вас, но я по крайней мере умею читать.
вы боитесь критики или уже считаете меня своим врагом???
вместо того, чтобы делать намеки наподобие "а сам...?", можете почитать статьи Зубинского в ko.itc.ua, замечательный автор, пишущий на замечательные темы. посмотрите, как тема дается у него.
вы боитесь критики или уже считаете меня своим врагом???
вместо того, чтобы делать намеки наподобие "а сам...?", можете почитать статьи Зубинского в ko.itc.ua, замечательный автор, пишущий на замечательные темы. посмотрите, как тема дается у него.
0
да нет, критика вся в тему, я в общем понимаю, что это до некоторой степени драфт кровью сердца.
просто Вы раз за разом пытаетесь всё же добиться того, чтобы я к Вам прислушался. И раз за разом новая информация заставляет меня скорее делать нечто обратное :)
это я ещё даже не стал пока читать, что там за статьи у Зубинского :)
просто Вы раз за разом пытаетесь всё же добиться того, чтобы я к Вам прислушался. И раз за разом новая информация заставляет меня скорее делать нечто обратное :)
это я ещё даже не стал пока читать, что там за статьи у Зубинского :)
0
Исконно русское слово драфт... А за статью спасибо. Вовремя.
0
От лица минимум одного "не умеющего" - всё понял и сделал выводы. Честно )
+1
Хорошая статья, спасибо. Хоть и работаю с свном уже давно, и многие вещи считаю практически естественными, но кое-что подчерпнул. Щас добавим вам "кармической силы" =)
+2
На счет коммента к коммиту с разрозненными пунктами: предполагается, что к такого рода комментам следует относиться уничтожающим вниманием на среднем и позднем этапах работы, так? Ведь на этапе дебюта можно, в самом деле, наворотить много делов и не факт, что они будет тесно связаны.
0
Спасибо. Почерпнул немного полезного. Есть рекомендации которые помогут в дальнейшем качественно хорошо работать в команде.
0
По diff перед коммитом. Ну так для себя чисто открыл colordiff и команда - "svn diff | colordiff | less -SR" - это вообще красота!!!
Про переименование файла - вот тут не согласен с двумя коммитами, вполне возможно обойтись и одним - просто надо правильно переименовывать (svn move), а потом правим этот файл и коммитим. SVN в этом сдучае дифф между версиями покажет нормальный.
Ну и в эндшпиле еще есть хорошая практика тэгов. То есть перед RC, или релизом версии (точнее во время) создается тэг - то есть непосредственно то что лежит на продакшене, что бы можно было с точностью взять код продакшена и попробовать воспроизвести на нём тот баг, который происходит.
Про переименование файла - вот тут не согласен с двумя коммитами, вполне возможно обойтись и одним - просто надо правильно переименовывать (svn move), а потом правим этот файл и коммитим. SVN в этом сдучае дифф между версиями покажет нормальный.
Ну и в эндшпиле еще есть хорошая практика тэгов. То есть перед RC, или релизом версии (точнее во время) создается тэг - то есть непосредственно то что лежит на продакшене, что бы можно было с точностью взять код продакшена и попробовать воспроизвести на нём тот баг, который происходит.
+1
в файле ~/.subversion/config можно определить diff-cmd = colordiff
0
svn diff | colordiff | less -SR
Вообще супер !
Вообще супер !
0
Согласен про один коммит. Вообще в статье много утверждений, не подкреплённых аргументами.
0
они подкреплены опытом
0
Опыт подразумевает, что вы пытались делать иначе и наступили на грабли, но вместо того, чтобы их описать, вы предлагаете просто делать два коммита. Почему читатель должен верить вам на слово?
0
«Смысл этого требования состоит в игре на благо будущего. Соблюдая его, можно быть уверенным, тот или иной коммит в потоке либо безопасен (например, фикс документации), либо может быть свободно откачен с уверенностью, что откатилось в точности одно логическое изменения. Это бесценное свойство при бинарном поиске ошибок. Более того, очевидно, что логичные изменения гораздо проще отсматривать в процессе код-ревью.»
0
>>Вопросы, пожелания, предложения?
Поясните хотя бы вначале сленговые слова, для того, чтобы непосвященным было понятнее раз, для того, чтобы выглядело по-человечески, а не перепиской в аське два. =)
А использование шахматных терминов порадовало :).
Ну и конечно, у меня сильное ощущение, что текст можно было бы сократить минимум в два раза, если бы поперечитывали и подредактировали.
Поясните хотя бы вначале сленговые слова, для того, чтобы непосвященным было понятнее раз, для того, чтобы выглядело по-человечески, а не перепиской в аське два. =)
А использование шахматных терминов порадовало :).
Ну и конечно, у меня сильное ощущение, что текст можно было бы сократить минимум в два раза, если бы поперечитывали и подредактировали.
0
это вобщем-то не сленговые слова, а команды и понятия из Subversion. Ежели вы пользуетесь SVN-ом, вам эти слова знакомы, а если вы только собираетесь пользоваться, то можно/нужно почитать что-то другое, перед этой статьей.
http://google.com/search?hl=ru&q=%D1%87%…
http://google.com/search?hl=ru&q=%D1%87%…
0
>> Мы молчим про пустые журнальные сообщения — это вообще худшее что может быть. Это допустимо только для совершенно далеких от программирования сотрудников (типа дизайнеров), которые на этот ваш сабвершен с трудом вообще согласились.
На эту тему удивил лог acts_as_state_machine, в котором вообще почти все коменты к коммитам пустые: http://codenotifier.com/projects/15
Мож у чувака какой-то стоит ловкий просмотрщик лога, который диффы сразу кажет - при том объеме кода комменты может и излишни.
На эту тему удивил лог acts_as_state_machine, в котором вообще почти все коменты к коммитам пустые: http://codenotifier.com/projects/15
Мож у чувака какой-то стоит ловкий просмотрщик лога, который диффы сразу кажет - при том объеме кода комменты может и излишни.
0
По поводу хранения кусков кода в закоментированном состоянии есть контр пример. Часто бывает, что какая-то функциональность не вынесена в отдельную структурную единицу (функцию или т.п.), а исключить её из основного кода надо. При этом точно известно, что она понадобится в будующем (ну или возможно понадобится). Если эту часть кода удалить, считая что в репозитории она всёравно есть, то возникнут две проблемы, когда её надо будет вернуть:
1. никто не вспомнит в какой ревизии оно отсюда исчезло (по diff-ам и blame-ам можно очдолго ползать, если уже много накоммитили)
2. даже если удастся достать этот кусок из репозитория, он может быть уже протухшим (изменились имена глобальных переменных и прочие последствия глобальных рефакторингов)
Поэтому в своей практике я вполне допускаю закоментированные куски кода, при условии, что "глобальные рефакторинги" на них распространяются. Да, это не гарантирует работоспособность (всётаки код не исполняется и никак проверить нельзя), но при достаточной аккуратности даёт больше чем удаление и надежда на репозиторий.
1. никто не вспомнит в какой ревизии оно отсюда исчезло (по diff-ам и blame-ам можно очдолго ползать, если уже много накоммитили)
2. даже если удастся достать этот кусок из репозитория, он может быть уже протухшим (изменились имена глобальных переменных и прочие последствия глобальных рефакторингов)
Поэтому в своей практике я вполне допускаю закоментированные куски кода, при условии, что "глобальные рефакторинги" на них распространяются. Да, это не гарантирует работоспособность (всётаки код не исполняется и никак проверить нельзя), но при достаточной аккуратности даёт больше чем удаление и надежда на репозиторий.
+1
Гм. А как рефакторинги могут распространяться на закомментированые куски кода? Я думал, sed-ом уже никто не рефакторит :). Или какие-то IDE-шки лазят в комментарии?
0
я может вас огорчу, но в мире существуют языки для которых автоматический рефакторинг не настолько хорош, как хотелось бы
когда пишешь на них приходится рефакторить "sed-ом", а иногда... вручную
когда пишешь на них приходится рефакторить "sed-ом", а иногда... вручную
0
Зря вы так про дизайнеров, не так там всё запущено. Другое дело, что часто правки дизайнерские описывать дольше, чем делать. в этом случае мы просто указываем, что было поправлено и указываем ID таска, где задача расписана более подробно, зачастую со скринами того, что надо сделать.
0
Какая-то СС'овская терминология у Вас :)) А вообще все можно упростить если на полную использовать merge.
0
что именно можно упростить, если на полную использовать мердж? и определите понятие "на полную". и скажите, в какой системе.
0
Проще сказать как делаем мы (как я понимаю, это классический подход). Система - subversion 1.5 (beta, с поддержкой merge tracking).
1) есть транк (основная ветка), куда делаюттся аккуратные, протестированные, логически целостные и задокумментированные коммиты. Сюда также коммитятся все багфиксы.
2) Для каждой мажорной фичи или версии создается бранч, куда можно коммитить грязно и беспорядочно, для ускорения процесса. Здесь допускаются битые ревизии. 3) Есть branches/stable, куда после тестирования тестером, перед рилизом, мерджатся все изменения в транке. 4) Бранчи мерджатся предварительно в транк.
"На полную" - как раз, используя svn 1.5/(1.4.99). У collabnet есть блог (ссылки не могу прилагать), где хорошо описываются недостатки ручного мерджа (да это просто ад), и то как он будет работать в 1.5.
1) есть транк (основная ветка), куда делаюттся аккуратные, протестированные, логически целостные и задокумментированные коммиты. Сюда также коммитятся все багфиксы.
2) Для каждой мажорной фичи или версии создается бранч, куда можно коммитить грязно и беспорядочно, для ускорения процесса. Здесь допускаются битые ревизии. 3) Есть branches/stable, куда после тестирования тестером, перед рилизом, мерджатся все изменения в транке. 4) Бранчи мерджатся предварительно в транк.
"На полную" - как раз, используя svn 1.5/(1.4.99). У collabnet есть блог (ссылки не могу прилагать), где хорошо описываются недостатки ручного мерджа (да это просто ад), и то как он будет работать в 1.5.
0
Ну вы герои, использовать нерелизнутый 1.5, который судя по тракеру ещё достаточно сырой. Что ещё тут можно сказать.
0
Бранч для каждой мажорной фичи? Не моноговато ли? Скажите, сколько у вас на текущий момент бранчей?
0
мажорная фича - пожалуй неверно сказано. Речь идет о переработке коры, любой рефакторинг и тд, все что не подлежит постоянному коммиту в транк и не является багфиксом. В данный момент всего одна, над которой идет работа. В новом TortoiseSVN, кстати, мердж минорных изменений в параллельной ветке (trunk->stable) отличается от мерджа из форкнутой(фичевой) ветки.
0
Если бы понял что-то, то наверно было бы очень интересно )))
0
Спасибо, хорошая статья. От себя добавлю, что полезно в лог коммита писать номер таска в баг(/таск)трекере.
И наверное вам надо было в начале статьи поставить ссылку на какую-нибудь вводную статью "Что такое контроль версий и с чем его едят" :)
И наверное вам надо было в начале статьи поставить ссылку на какую-нибудь вводную статью "Что такое контроль версий и с чем его едят" :)
+1
Не понятно, почему вы не написали, что trac с subversion особенно хорош с trac'овским hook'ом на post-commit. В этом случае появляется возможность закрывать задачи и писать в комментарии к задачам с помощью log message.
0
А не помнит ли кто-нибудь линк на статью про git на хабре? Вообще было бы интересно почитать нечто подобное про git, ибо есть нюансы.
И еще автору: мне кажется было бы мега полезно привести примеры правильных и неправильных коммитов (особенно description-ов).
И еще автору: мне кажется было бы мега полезно привести примеры правильных и неправильных коммитов (особенно description-ов).
0
Cпасибо за статью, воспринимается легко и познавательно. По поводу предложений, хотелось бы в таком же стиле статью про управление ветками (branches), про то как правильно создавать, коммитить, обьединять и разрешать конфликты.
0
Насчёт хорошей документируемости коммитов.
Нельзя не упомянуть, как в контексте исследования старого (legacy) кода,
так и в качестве наказаний для молчунов (пустые логи) и лентяев (лог просто "fixed") о возможности править svn:log:
svn pe svn:log -r XXX --revprop
В первом случае позволяет удобным образом хранить замечания о давних (и невнятных) коммитах, во втором... заменить битьё по рукам полезным деянием.
Нельзя не упомянуть, как в контексте исследования старого (legacy) кода,
так и в качестве наказаний для молчунов (пустые логи) и лентяев (лог просто "fixed") о возможности править svn:log:
svn pe svn:log -r XXX --revprop
В первом случае позволяет удобным образом хранить замечания о давних (и невнятных) коммитах, во втором... заменить битьё по рукам полезным деянием.
+1
Большое спасибо. Жму руку, тащу в корпоративную вики (копирайты сохраняю, конечно :).
0
Корпоративная вики, а вы случайно Trac не пользуетесь? Там есть встроенная вики. Мы на данный момент используем её.
Или у вас какой-то другой движок?
Или у вас какой-то другой движок?
0
Trac не пользуемся. Используем MoinMoin, http://www.google.ru/search?q=moinmoin, рекомендую от всей души. Но в виках главное вовсе не движок, главное контент, а движок дело вкуса и удобства. :)
0
особо нового ничего для себя не вынес, но спасибо!
зы особенно хорошо с результатами коммитов IJ Idea умеет работать - сама проверит обновления, покажет чейджлог, предупредит перед началом изменения файла, что он уже устарел.
зы особенно хорошо с результатами коммитов IJ Idea умеет работать - сама проверит обновления, покажет чейджлог, предупредит перед началом изменения файла, что он уже устарел.
0
спасибо, полезная заметка. еще чуть упорядочить текст и немного примеров, поясняющих каждый абзац и получится отличная статья.
0
Некоторые замечания по названиям фаз разработки (дебют, миттельшпиль и эндшпиль)
Мне как-то привычнее общепринятые термины feature-freeze, code-freeze, system-test-freeze,
на которых всё меньше вносится крупных изменений в код и добиваются большей стабильности, всё жестче ограничения на коммиты.
Мне как-то привычнее общепринятые термины feature-freeze, code-freeze, system-test-freeze,
на которых всё меньше вносится крупных изменений в код и добиваются большей стабильности, всё жестче ограничения на коммиты.
0
Sign up to leave a comment.
Subversion: чеклист по правильным коммитам