что значит «дублирует тэги»?
по памяти все нормально, структура в любом случае получается достаточно компактной. Можно еще оптимизировать, но это уже в качестве домашнего задания :)
все дело в том если он уже говрил о том что нам нужны тестеры, и делал это на протяжении полугода, созывал всех в переговорную, твердил это менеджеру каждый день, а ему говорили «да, да ты прав», но их так и не появилось. И он уже в который раз после выгрузки сидит все выходные и вылавливает баги, о которых почему то никто до выгрузки так и не слышал.
а потому что ему надоело уже вам говорить что надо делать что бы этого не приходилось делать никому. но вы же самый умный а он кто такой что бы советовать
внезапно знаете что бывает? :)
в реальности проект не может внезапно разонравится. вчера нравился а сегодня понял что херня. не бывает такого. обычно это происходит постепенно, и у этого есть причины. и чаще всего это ошибки управления.
ok.
а есть ли в CVS Externals Definitions?
как насчет отсутвия Merge tracking?
как вы думаете почему даже такой старый и большой проект как FreeBSD таки перешел на SVN?
я так и знал что вы это заметите :) Но дело в том, что после этих комментариев я начал использовать меркуриал в одном проекте, а недавно мне оне популярно объяснили что оказывается в другом моем проекте, который опен сорс, мне нужен GIT, но все не доходят руки под него проект перевести. Но то что это нужно сделать я не сомневаюсь. То есть скепсис понятен, и это нормально. А вот упертость это уже плохо.
дело в том, что он итак посмотрит. но тогда, когда придет его очередь писать код в этом участке. смотрите, система проста. программист комитит код в свою ветку. мержит из транка последние изменения. после этого, отдает тестерам на тестирование. они тестируют, и если код правильно работает, он реинтегрируется в транк. но вдруг код недостаточно хорошо написан? в следующий раз менеджер, дает этот участок кода доработать более опытному. то есть не специально для ревизии, а для доработки функционала. более опытный смотрит на код, и проводит рефактроинг. и если считает нужным подзывает к себе джуниора и показывает его недочеты. таким образом не тратится время дорогого специалиста а убивается сразу 2 зайца.
так же полезна практика парного программирования. во первых и код пишется быстрее, и программисты друг у друга учатся и друг за другом следят.
но повторяю, даже если и использовать ревизии, это все равно нисколько не мешает частым комитам. Наоборот, если уж так важна инспекция, можно слать архитектору диф комита. И ему будет гораздо проще следить за кодом и видеть изменения.
я к тому что частый комит и мердж никак не мешает инспекции кода. хотя и сама инспекция это бред. есть тестирование, это да, это нужно. но инспектировать код не нужно.
1. нужно избегать говнокодеров еще на этапе собеседования
2. плохо написанный код, если при этом написаны тесты со временем вылизывается. это называется TDD. А если вы дрожите деньгами, вам просто необходим принцип минимализма. То есть все что требуется от кода это то что бы он выполнял поставленную задачу. НО это только в том случае если у вас в целом все процессы верные, если у компа не говнокодеры, если пишете юниттесты, если код изначально хорошо структурирован… то есть правильно поставленная работа не требует контроля именно кода. но это не отменяет необходимость его тестирования, что невозможно без комита, иначе откуда тестеры его возьмут
1. Какая проверка? Вы экономите на переходе на svn при этом впустую тратите людские ресурсы.
2. Для того что бы непроверенный код не попадал в ночной билд и существуют ветки. Закомитился, и проверяй сколько влезет. Проеврил, прогнал тесты комить в билдовую ветку.
Это доказывается логикой. Чем чаще мерж тем меньше конфликтов. на мерж тратится 15 сек. на разруливание конфликта от нескольких минут до бесконечности. Надо взять за правило
1. часты комит. несколько раз в день. любое более или мение законченное изменение должно тут же комитится. не нравится длинную команду набирать, присовй элиас (или вы через гуи работаете?)
2. частый мерж. закомитил, тут же смержился. в svn это делается простейшей командой, не надо номера ревизий запоминать все помнится автоматически.
Вот в этом ваша проблема. У нас тоже подобные проблемы были. Ну никак не вдолбишь ты людям что надо часто комитится и мержится. работают днями, а потом часы тратят на разруливание конфликтов. причем не только те кто не комитится и не мержится, а и те кто работает правильно.
Статью я писать не буду, потому что она неактуальна. Все умные люди давно перешли на более совершенные системы контроля версий, и мало кому нужно доказывать их приемущества.
по памяти все нормально, структура в любом случае получается достаточно компактной. Можно еще оптимизировать, но это уже в качестве домашнего задания :)
вы наверное путаете работу и рабство.
в реальности проект не может внезапно разонравится. вчера нравился а сегодня понял что херня. не бывает такого. обычно это происходит постепенно, и у этого есть причины. и чаще всего это ошибки управления.
Мне нравится другое выражение: «Не доводи до фанатизма» :)
я вполне способен доводить работу до конца. тут вы не правы.
а есть ли в CVS Externals Definitions?
как насчет отсутвия Merge tracking?
как вы думаете почему даже такой старый и большой проект как FreeBSD таки перешел на SVN?
habrahabr.ru/blogs/development_tools/45203/
habrahabr.ru/blogs/development_tools/45222/
хотя лучшая статья это svnbook ;)
так же полезна практика парного программирования. во первых и код пишется быстрее, и программисты друг у друга учатся и друг за другом следят.
но повторяю, даже если и использовать ревизии, это все равно нисколько не мешает частым комитам. Наоборот, если уж так важна инспекция, можно слать архитектору диф комита. И ему будет гораздо проще следить за кодом и видеть изменения.
1. нужно избегать говнокодеров еще на этапе собеседования
2. плохо написанный код, если при этом написаны тесты со временем вылизывается. это называется TDD. А если вы дрожите деньгами, вам просто необходим принцип минимализма. То есть все что требуется от кода это то что бы он выполнял поставленную задачу. НО это только в том случае если у вас в целом все процессы верные, если у компа не говнокодеры, если пишете юниттесты, если код изначально хорошо структурирован… то есть правильно поставленная работа не требует контроля именно кода. но это не отменяет необходимость его тестирования, что невозможно без комита, иначе откуда тестеры его возьмут
2. Для того что бы непроверенный код не попадал в ночной билд и существуют ветки. Закомитился, и проверяй сколько влезет. Проеврил, прогнал тесты комить в билдовую ветку.
щас я вас сэконосмлю несколько миллионов)))
Это доказывается логикой. Чем чаще мерж тем меньше конфликтов. на мерж тратится 15 сек. на разруливание конфликта от нескольких минут до бесконечности. Надо взять за правило
1. часты комит. несколько раз в день. любое более или мение законченное изменение должно тут же комитится. не нравится длинную команду набирать, присовй элиас (или вы через гуи работаете?)
2. частый мерж. закомитил, тут же смержился. в svn это делается простейшей командой, не надо номера ревизий запоминать все помнится автоматически.
Вот в этом ваша проблема. У нас тоже подобные проблемы были. Ну никак не вдолбишь ты людям что надо часто комитится и мержится. работают днями, а потом часы тратят на разруливание конфликтов. причем не только те кто не комитится и не мержится, а и те кто работает правильно.