Здравствуйте, Lloyd, Вы писали:
__>>ну и каждый раз когда svn сервер отваливается тоже только укрепляюсь в своем мнении. плюс — ты точно уверен что на что у тебя заменяется и можешь тут же посмотреть, а не через ректальный доступ к серверу с интерфейсов svn (часто еще и медленный, если он заграницей).
L>А ты точно уверен, что у тебя лежит на диске и можешь тут же посмотреть, а не через ректальный доступ к диску с интерфейсов файловой системы?
проект обычно раскидан по папочкам. до сих пор проблема поиска такого-то текста в такой-то подпапочке из студии не решена. поиск по проекту когда нужный текст находится на следующий строке в студии занимает секунд 5.

L>Страхи из разряда "обжегшись на молоке, на воду дуют". Страхи наде не культивировать, а бороться с ними. Со времен SourceSafe уже как минимум лет 10 прошло, с того времени ой как много изменилось.
вот отвалился у вас интернет ли сервер svn перегружается. что делать будете? чаи гонять, ждать? зачем вы создали себе гемор на ровном месте пользуясь svn для быстрых рабочих снапшотов?
вот вы приехали в командировку и решили что-то поделать на ноуте. доступ к серверу тормозной до ужаса. что будете делать?

L>В 3 ночи надо спать, а не беситься от окошек. А новые инструменты надо изучать и использовать к своей выгоде, а не руководствоваться принцыпом "мне так привычнее". Будь у меня розовый слоник в аватарке, я бы напомнил вам о парадоксе блаба.
L>С таким подходом вы лет через 10 "на помоечке" (с) окажетесь.
это касается моей личной внутренней организации работы. она должна быть максимально простой, быстрой и надежной. хранение в svn рабочих снапшотов как минимум медленней и точно менее надежна — вероятность что отвалится сервер или сеть выше, чем полетит винт.

насчет git — понимаю, что перспективно, и идеально подходит для того, чего был создан. мне не нужен.

__>по уму все коммиты должны быть атомарными. грубо говоря одна фича или фикс — один коммит.
__>говорит о том, что вы наделали 1000 фич или фиксов, потратили в среднем на одну штуку полчаса. скорее всего фиксы.

Это вы сами придумали или где-то такое написано? По уму используют либо распределенную систему которая коммитит в себя, либо feature branches в svn и коммитят в него, а когда все заработало и стабилизировалось — сливают этот бранч в транк.

Делают это для того, чтобы коммиты были небольшими — по нескольку строчек. Небольшие коммиты благотворно влияют на code review, позволяют вынести значительную часть документации из исходников в комментарии к коммитам, делают blame на порядок более читаемым.

Если посмотреть на популярные open source проекты, то можно увидеть за последние несколько лет тенденцию к уменьшению размера одного коммита. Этому способствуют как распределенные системы типа Git, так и нормальным бранчи в SVN начиная с версии 1.5

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

M>О том, что инструмент изначально выбран неверно. С таким подходом, вам нужно использовать git или хотя бы git интерфейс для svn. В противном случае через 5000 часов у вас будут серьезные проблемы при работе с историей: будет очень трудно разобраться когда и зачем было произведено конкретное изменение.

Это почему, если не секрет? Та же TortoiseSVN очень хорошо показывает историю — с фильтрами, указанием что из каких бранчей мерджилось.

MTD>Я однажды смотрю в репозитории странная активность — от одного персонажа по несколько коммитов в час. Стал смотреть. Оказывается он по одному файлу комитил Так что говорит это о том, что ты скорее всего не умеешь пользоваться системой контроля версий

... Или наоборот — умеет. В последнее время наблюдается тенденция уменьшения размеров коммита. Для соблюдения политики "stable trunk" достаточно использовать распределенную сстему контроля версий которая умеет коммитить локально либо бранчи в SVN, которые починили еще в версии 1.5. Мелкие коммиты по нескольку десятков строк гораздо лучше поддаются code review, позволяют переместить часть комментариев из кода в коммиты, улучшают blame и вообще благоприятно влияют на процесс разработки.

Здравствуйте, Eye of Hell, Вы писали:
EOH>Делают это для того, чтобы коммиты были небольшими — по нескольку строчек. Небольшие коммиты благотворно влияют на code review, позволяют вынести значительную часть документации из исходников в комментарии к коммитам, делают blame на порядок более читаемым.
фичи тоже по пару строк коммитите?

EOH>И да, feature branch никто не делает ручками — для этого есть специально обученные скрипты которые по нажатию одной кнопки создают такой бранч под задачу, а по нажатию другой — мерджат его в транк и удаляют.
о, еще и скрипты. сколько гемора наворочено ради такой простой задачи.

EOH>>Делают это для того, чтобы коммиты были небольшими — по нескольку строчек. Небольшие коммиты благотворно влияют на code review, позволяют вынести значительную часть документации из исходников в комментарии к коммитам, делают blame на порядок более читаемым.
__>фичи тоже по пару строк коммитите?

Фича = несколько коммитов по паре строк?

EOH>>И да, feature branch никто не делает ручками — для этого есть специально обученные скрипты которые по нажатию одной кнопки создают такой бранч под задачу, а по нажатию другой — мерджат его в транк и удаляют.
__>о, еще и скрипты. сколько гемора наворочено ради такой простой задачи.

Напомните, какую задачу вы называете "простой"? Разработку ПО?

Здравствуйте, Eye of Hell, Вы писали:
EOH>>>Делают это для того, чтобы коммиты были небольшими — по нескольку строчек. Небольшие коммиты благотворно влияют на code review, позволяют вынести значительную часть документации из исходников в комментарии к коммитам, делают blame на порядок более читаемым.
__>>фичи тоже по пару строк коммитите?
EOH>Фича = несколько коммитов по паре строк?
фича это новая функциональность. новые классы, ф-ии, часто файлы

EOH>>>И да, feature branch никто не делает ручками — для этого есть специально обученные скрипты которые по нажатию одной кнопки создают такой бранч под задачу, а по нажатию другой — мерджат его в транк и удаляют.
__>>о, еще и скрипты. сколько гемора наворочено ради такой простой задачи.
EOH>Напомните, какую задачу вы называете "простой"? Разработку ПО?
задача "хранения рабочих черновиков".

Здравствуйте, Miroff, Вы писали:

M>Здравствуйте, a.k.m., Вы писали:

AKM>>о чем то этот показатель говорит?

M>О том, что инструмент изначально выбран неверно. С таким подходом, вам нужно использовать git или хотя бы git интерфейс для svn. В противном случае через 5000 часов у вас будут серьезные проблемы при работе с историей: будет очень трудно разобраться когда и зачем было произведено конкретное изменение.

а в чем конкретно будет видна разница через 5000 часов между svn и git?
(с git имел дело лишь мельком)

Здравствуйте, __kot2, Вы писали:

__>>>фичи тоже по пару строк коммитите?
EOH>>Фича = несколько коммитов по паре строк?
__>фича это новая функциональность. новые классы, ф-ии, часто файлы

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

EOH>>>>И да, feature branch никто не делает ручками — для этого есть специально обученные скрипты которые по нажатию одной кнопки создают такой бранч под задачу, а по нажатию другой — мерджат его в транк и удаляют.
__>>>о, еще и скрипты. сколько гемора наворочено ради такой простой задачи.
EOH>>Напомните, какую задачу вы называете "простой"? Разработку ПО?
__>задача "хранения рабочих черновиков".

Эта задача топикстартера или ваша? Какое она вообще имеет отношение к коммитам и контролю версий?

Здравствуйте, __kot2, Вы писали:

AKM>>читайте внимательно, что я пишу
AKM>>отдельный бранч только на период разработки отдельной фичи, когда человек коммитит 2 раза в час
AKM>>по завершении фичи (то есть от 3 раз в день до 1 раза в неделю) обязательный мердж с основным общим бранчем
__>и зачем все эти телодвижения?
__>я просто в Far'e делаю копию в отдельную папочку, если приступаю за серьезную модицикацию и боюсь что все заглючит — чтобы откатиться назад

Например, можно сделать несколько промежуточных коммитов, которые реализуют часть фичи. И потом смёрджить всё.
Удобно, когда 1 коммит содержит последовательность действий, логически связанных друг с другом. Когда всё в куче, то разобраться тяжелее.

Здравствуйте, Eye of Hell, Вы писали:
__>>>>фичи тоже по пару строк коммитите?
EOH>>>Фича = несколько коммитов по паре строк?
__>>фича это новая функциональность. новые классы, ф-ии, часто файлы
EOH>Тоесть новые классы, функции, файлы не разбиваются на небольшие коммиты и коммитятся монолитом по нескольку сотен строк? .
да. я же говорю: одна фича — один коммит.

EOH>>>Напомните, какую задачу вы называете "простой"? Разработку ПО?
__>>задача "хранения рабочих черновиков".
EOH>Эта задача топикстартера или ваша? Какое она вообще имеет отношение к коммитам и контролю версий?
вы не соображаете о чем говорите. мы именно это и обсуждаем — зачем топикстартеру понадобилось столько коммитов мелких.
специально для тупых повторяю историю разговора — я предположил, что это фиксы. топикстартер говорит что это не фиксы, а черновики.

Здравствуйте, alzt, Вы писали:
A>Например, можно сделать несколько промежуточных коммитов, которые реализуют часть фичи. И потом смёрджить всё.
A>Удобно, когда 1 коммит содержит последовательность действий, логически связанных друг с другом. Когда всё в куче, то разобраться тяжелее.
вот недавно был 50 тысячный коммит по-моему. удобнее было бы иметь их в 10 раз больше?

__>Здравствуйте, Eye of Hell, Вы писали:
__>>>>>фичи тоже по пару строк коммитите?
EOH>>>>Фича = несколько коммитов по паре строк?
__>>>фича это новая функциональность. новые классы, ф-ии, часто файлы
EOH>>Тоесть новые классы, функции, файлы не разбиваются на небольшие коммиты и коммитятся монолитом по нескольку сотен строк? .
__>да. я же говорю: одна фича — один коммит.

А вот текущие тенденции наоборот рекоменуют делать мелкие коммиты, где одна фича — это много коммитов. Берем любой успешный проект на гитхаб (я бы, конечно, предложил взять успешный проект от гугл — но кто ж даст?) и смотрим на коммиты. Они — мелкие. И каждая фича, если она не в пару строк, состоит из кучки небольших коммитов.
Опять же мой небольшой пятнадцатилетний опыт коммерческой разработки подсказыает, что чем меньше размер коммита — тем легче потом делать code review, читать blame, да и вообще комментарии переносятся из кода и вики в историю коммита, где их намного удобнее читать.

EOH>>>>Напомните, какую задачу вы называете "простой"? Разработку ПО?
__>>>задача "хранения рабочих черновиков".
EOH>>Эта задача топикстартера или ваша? Какое она вообще имеет отношение к коммитам и контролю версий?
__>вы не соображаете о чем говорите. мы именно это и обсуждаем — зачем топикстартеру понадобилось столько коммитов мелких.
__>специально для тупых повторяю историю разговора — я предположил, что это фиксы. топикстартер говорит что это не фиксы, а черновики.

Да никто не спорит что у вас длиннее, зачем столько экспрессии?

Здравствуйте, Eye of Hell, Вы писали:
EOH>А вот текущие тенденции наоборот рекоменуют делать мелкие коммиты, где одна фича — это много коммитов. Берем любой успешный проект на гитхаб (я бы, конечно, предложил взять успешный проект от гугл — но кто ж даст?) и смотрим на коммиты. Они — мелкие. И каждая фича, если она не в пару строк, состоит из кучки небольших коммитов.
EOH>Опять же мой небольшой пятнадцатилетний опыт коммерческой разработки подсказыает, что чем меньше размер коммита — тем легче потом делать code review, читать blame, да и вообще комментарии переносятся из кода и вики в историю коммита, где их намного удобнее читать.
я тоже люблю маленькие коммиты. и фиксы мои часто это одна строчка.
я говорю именно про разработку фич.
вот представим например, что человек пишет новый контейнер stl. вот vector. вы он завел новый файл, написал шапку сверху и class vector{}. что, уже коммититься?
потом он пишет конструктор. новый коммит?
зачем? кому нужна такая хрень?

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

Здравствуйте, __kot2, Вы писали:

__>я тоже люблю маленькие коммиты. и фиксы мои часто это одна строчка.
__>я говорю именно про разработку фич.
__>вот представим например, что человек пишет новый контейнер stl. вот vector. вы он завел новый файл, написал шапку сверху и class vector{}. что, уже коммититься?
__>потом он пишет конструктор. новый коммит?
__>зачем? кому нужна такая хрень?

Первый коммит — скелет (шапка, конструктор-деструктор).
Второй и последующие коммиты — добавление функционала маленькими кусочками.
Хрень нужна ряду нехорших людей:
1. Тому, кто будет делать code review. Потому как когда через три дня работы над этим супер вектором 500 строчек таки закоммитят, то читать это будет — ад. Я сам руковожу разработкой, регулярно делаю code review. Большие коммиты — ад как он есть.
2. Тому, кто будет впоследствии этот класс поддерживать и захочит выяснить, зачем где-то стоит if. Если там коммиты по сто строк вида "добавил функциональность кеширования." — то фиг разберешся. А вот если коммиты мелкие — то они исподволь заставляют разработчика протоколировать свои действия, что потом намного удобнее читать.

Здравствуйте, __kot2, Вы писали:

__>моя философия, что в транк нужно коммитить только 100% удостоверившись, что то, что коммитишь, лучше, чем то, что в транке. недописанная или непротестированная функциональность это гавно на палочке. ей не место в транке. ей место только у вас на компе. зачем кому-то нужен вектор, который умеет только инициализироваться?

Я, пожалуй, сам себя процетирую, выше по ветке:
eye>Это вы сами придумали или где-то такое написано? По уму используют либо распределенную систему которая коммитит в себя, либо feature branches в svn и коммитят в него, а когда все заработало и стабилизировалось — сливают этот бранч в транк.

Мелкие коммиты никак не влияют на собираемость транка. Их делают либо локально (git, mercurial) либо в специальный feature branch (svn).

Здравствуйте, a.k.m., Вы писали:

AKM>о чем то этот показатель говорит?
Этот показатель может говорить о многом

Автор: мыщъх
Дата: 31.01.12

, но в конкретно Вашем случае — он не говорит ни о чем.

Здравствуйте, __kot2, Вы писали:

A>>Удобно, когда 1 коммит содержит последовательность действий, логически связанных друг с другом. Когда всё в куче, то разобраться тяжелее.
__>вот недавно был 50 тысячный коммит по-моему. удобнее было бы иметь их в 10 раз больше?

Зависит от коммитов. Если коммиты в виде "Сделал всплывающее окошко", "Реализовал сериализацию какой-то штуки", то хоть их в 100 раз больше, пользоваться не сложно.
А если в виде "куча кода для работы с принтером", то разобраться в этом посложнее.

EOH>А вот текущие тенденции наоборот рекоменуют делать мелкие коммиты, где одна фича — это много коммитов.

И как это тестируется?
Любой коммит не должен рушить автотесты (мы же обсуждаем нормальную работу, с test-first approach?)
Соответственно, если этот коммит однострочный, он что-то добавляет в работу системы (или, например, добавляет только тесты — т.е. ничего в основной код не идет, только в тесты) — это вполне правильный и полноценный коммит.

А если это коммит чисто "хочу забэкапить, а то завтра у меня выходной и я забуду что делал" — это IMHO вредно, т.к. почем зря триггерит всю сборочную автоматизацию. Увеличивает official build number, гоняет все (в т.ч. интеграционные, нагрузочные и т.п.) тесты, выкладывает обновленные версии библиотек. Много еще чего может быть на это дело завязано.