А вот как у вас модно

[metaclass]

работать с системами контроля версий? Конкретно, с subversion, потому что в меркуриале и прочих DVCS можно хоть обкоммитится до одури - пока в другой репозиторий не закинешь, этого никто не увидит.

Я как-то склоняюсь к "сделал независимый мелкий кусок - тут же закомитил", даже если там пару букв всего поменялось. Т.е. билд стараться не ломать принципиально, но накапливать изменения на "один огромный коммит на всю фичу" не хочу.

PS: В комментариях много советуют бранчи. Я почему-то никогда ими не пользовался, сначала в svn они были адом и мне лень было это осиливать, а сейчас как-то никогда не возникает надобности. Т.е. организация проекта и релизов как-то так получилась, что борьба с бранчами не стоит того.

Comments

[dmzlj.livejournal.com]

1. Это когда вы коммитите пачку файлов, а в одном возьми, да и случись конфликт. И тогда те, в которых конфликта не было закоммитятся, а вот это файл - увы. И что самое смешное --- это можно еще и не заметить, что регулярно и случалось.

2. Сырой код или не сырой --- определяется тестированием. Определяют, это соответственно, уже после включения всех изменений в релизную ветку и прогона тестов. Не сломались тесты --- значит не сырой. Ну и куча мусорных коммитов в общей ветке --- это именно бардак, а управлять коммитами в CVS способа нету.

3. Потеря истории --- это и есть бардак в чистом виде.

4. Про code freeze --- без комментариев.

А решение одно: если принять решение о выбрасывании CVS на уровне организации воли нету, что говорит о том, что у руля стоят совершенно замшелые пни, то выкинуть его локально, и для себя пользоваться чем-то вроде git-cvs, и в общий реп коммитить уже более-менее осмысленными кусками.

[psilogic.livejournal.com]

1. Способ лечения: использовать .cvsignore, опция -q (quiet)
В результате конфликт трудно не заметить, так как вывод не загроможден лишним текстом.

2. Ну так в чем бардак то?

3. Это просто лозунг. По-вашему - бардак, по-моему - мелочь.

4. As you wish :)

Пни не замшелые, просто CVS не настолько критичный инструмент, чтобы возиться с его заменой.

[dmzlj.livejournal.com]

1. Это вообще не способ лечения. И потом, что вылечим-то? Часть файлов не закоммитилась, часть закоммитилась. Потом пока коммитер чешет репу что бы такого сделать всвязи с ситуацией, остальной табун, который коммитит в ту же ветку (бранчей-то нет), сверху уже накидает новых коммитов уже, усугубляя ситуацию.

2. Бардак в том, что разработчик или вынужден не коммитить до последнего, тормозя свою разработку и рискуя потерять изменения, либо коммитить мусор (бессмысленные мелкозернистые коммиты) в основную ветку

3. Ну все мелочь по сравнению с тепловой смертью вселенной, кто же спорит.

4. Ну информация как бы не секретная, термин распространенный. Если сталкиваться не приходилось, то какой смысл обсуждать.

Замена CVS хотя бы на SVN --- вопрос одного-двух дней. А отсутствия нормального контроля версий скорее всего говорит о практически отсутствующем управлении релизами. Что прискорбно.

[psilogic.livejournal.com]

1. Как не способ? Благодаря таким мерам вы видите, что есть конфликт и просто исправляете его. Если прозевали, и какой-то файл оказался незакоммиченным, то исправите его чуть позже.

2. Я же объяснил, как это преодолевается - коммитите, просто в сборку не включаете.

3. :)

4. Это моя слабость - плохо запоминаю звучные термины. Так что может и сталкивался с чем-то похожим, но не знаю, что это называется именно так.

[ Замена CVS хотя бы на SVN --- вопрос одного-двух дней. ]

Плюс время привыкания к глюкам нового инструмента - N дней. И через сколько те 1-2 дня + N дней окупятся? И ради чего огород городить? Инструмент то не ключевой - не компилятор какой-нибудь.

[dmzlj.livejournal.com]

По поему, система контроля версий это ключевой инструмент, в некотором смысле более ключевой, чем компилятор. Очень много на него завязано: можно и метрики снимать, и релизами управлять, и code review и т.п.

Насчет глюков хотелось бы подробнее. Как бы этими инструментами пользуются миллионы человек ежедневно, врядли вот новые пользователи прямо сходу придут и обнаружат на повержности какие-то прямо глюки, до них никем не виданные. Если только глюки в своих головах.

SVN практически не отличается от CVS, только сделан чуть более по-человечески. Так что особенно привыкать не к чему.

Окупаться начнет не использование нового контроля версий, а более упорядоченная разработка. Например, за счет того, что меньше станет тратиться времени на борьбу с особенностями инструментария.

[psilogic.livejournal.com]

[ Насчет глюков хотелось бы подробнее. ]

Здесь я имею в виду специфические трудности, которые возникают при работе с данным инструментом и к которым надо приноровиться, понять, как с ними дешево бороться. Ну как невозможность легко отследить переименование в CVS - наверняка в "черепашке" есть свои подобные заморочки.

[ Окупаться начнет не использование нового контроля версий, а более упорядоченная разработка. ]

Я это понимаю. Вопрос в том, за сколько оно окупится. В наших проектах выгода неочевидна. Была бы очевидна - перескочили бы со свистом. По сравнению с ежедневным переключением с C++ на Java потом на Delphi потом обратно - это не проблема.

[dmzlj.livejournal.com]

Я это понимаю. Вопрос в том, за сколько оно окупится. В наших проектах выгода неочевидна. Была бы очевидна - перескочили бы со свистом. По сравнению с ежедневным переключением с C++ на Java потом на Delphi потом обратно - это не проблема.

Ну ведь на этот вопрос нельзя ответить в общем? Можно только вести учет времени, потраченные на отдельные активности разными людьми, и смотреть сколько времени ушло на борьбу с CVS.

После CVS трудностей не будет. Наоборот, будет ощущение, что долгие годы над вами издевались, и вдруг, ВНЕЗАПНО, перестали.

У меня был опыт работы в довольно крупном проекте (1+ Gb исходников + 11 человек), где на поддержание CVS в норме время тратилось постоянно.

Писались внешние скрипты для обработки тех или иных ситуаций, постоянно были проблемы из-за недокоммиченных файлов (писались скрипты противодейтствия этому), регулярно случался code freeze, что бы стабилизировать релиз (это когда не делается новых изменений, только фиксы и вся команда с удовольствием курит бамбук).

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

[psilogic.livejournal.com]

[ Наоборот, будет ощущение, что долгие годы над вами издевались, и вдруг, ВНЕЗАПНО, перестали. ]

Ну возможно :)

code freeze - теперь я понял, о чем вы - да, такое у нас бывает регулярно. :)

Мера борьбы - как только удается получить стабильную версию de facto (а такое периодически случается), она отмечается специальным тегом и вот это предъявляется как последняя версия потенциальным заказчикам. Так что бамбук в результате никто не курит. А вот когда старались получить стабильную версию к заранее заданной дате - тогда да, бывали и бамбуки.

Из-за недокомиченности файлов бывают минутные проблемы:
- Мужики, у меня ### не собирается, кто последний там насрал?
- Вроде я. Сейчас проверю...
через 1 минуту:
- Все, закоммитил, собирай.
- Все, собралось.

[dmzlj.livejournal.com]

Мера борьбы - как только удается получить стабильную версию de facto (а такое периодически случается), она отмечается специальным тегом и вот это предъявляется как последняя версия потенциальным заказчикам. Так что бамбук в результате никто не курит.

Да ну? А фиксы на нее коммитить по результатам тестов?

Из-за недокоммиченности проблемы минутные, если сразу удалось заметить. А если не сразу, то проблема может быть зарыта сколь угодно глубоко.

[psilogic.livejournal.com]

[ Да ну? А фиксы на нее коммитить по результатам тестов? ]

В какой-то момент оказывается, что все тесты успешны, все фиксы прокоммичены, все классно - этот момент ловится и метится тегом как очередная эталонная версия.

Не сразу заметить - так не бывает. Весь проект собирается целиком 1-2 раза в день и еще N раз на машинах разработчиков. Если что-то не закоммичено, этот факт остается незамеченным максимум несколько часов.

[dmzlj.livejournal.com]

Ну как бы объяснить. Вот есть количество функционала, запланированное на очередной релиз. Настал этап фриза и тестиравания. В принципе те, кто давно сделал свои задачи на текущий релиз, могли бы приступать к задачам на следующий релиз.

Что-то делать остается только тем, кому надо фиксить в своей зоне ответственности.

И если нет нормальных бранчей, то неизбежно простаивание части команды. В принципе --- может быть, это даже кому-то нравится, поэтому внедрение инструментария, который позволит построить работу более эффективно, было бы воспринято в штыки.

Что до поломок от неатомарных коммитов --- то хорошо, если они сборку ломают. А если не ломают --- то может быть все, что угодно. Ну, просто баг благодаря системе контроля версий, которого могло бы не быть.

[psilogic.livejournal.com]

[ Вот есть количество функционала, запланированное на очередной релиз. Настал этап фриза и тестиравания. В принципе те, кто давно сделал свои задачи на текущий релиз, могли бы приступать к задачам на следующий релиз. ]

Да, я вас прекрасно понимаю, у нас когда-то так и было, и описанные вами проблемы задалбывали. Но потом просто перешли на другую организацию процесса разработки, и этот вопрос отпал сам собой. Понятно, что можно делать бранчи и даже делаем иногда, но по факту это оказывается необходимо настолько редко, что в принципе могли бы обойтись и без них.

[metaclass.livejournal.com]

По моему, системы контроля версий это сильно более ключевой инструмент, чем компиляторы, но менее ключевой чем баг-трекеры :)

[psilogic.livejournal.com]

Не... без компилятора вообще х. че сделаешь, а система контроля версий в простейшем случае реализуется тупо как серия еженедельных архивов.

[dmzlj.livejournal.com]

Но ведь и компиляторы и VCS уже есть. Вам ведь не надо их писать?

Еженедельных... OMFG...

[psilogic.livejournal.com]

Можно и ежемесячных - смотря что за проект :)

Скажем, у меня есть личный проект - размер большой, но делаю его только я. Так мне по горло хватает совершенно вырожденного версионного контроля: каждый вечер zip проекта на hard и на флешку, каждый месяц - сохранение ZIP-а под отдельным именем в папке.

То есть, можно без версионника ВООБЩЕ, а вот без компилятора - никак.

[dmzlj.livejournal.com]

Ну то есть если там форсмажор случится --- то потерять неделю или месяц работы не жалко.

Ну там про мелкие удобства неограниченного rollback, что бывает полезно в случае разного рода исследований я не говорю.

Я мессаджа не понимаю. Вот есть DVCS. Исключительно удобны: почти не требуют инсталляции, конфигурации. Дают много возможностей и удобств. Какой смысл ими не пользоваться?

[psilogic.livejournal.com]

[ Ну то есть если там форсмажор случится --- то потерять неделю или месяц работы не жалко. ]

Вы тут смешиваете backup и версионный контроль. Потерять неделю - это если вы делаете backup раз в неделю. А я говорю о сохранении раз в неделю очередной версии для отката назад. Backup хоть раз в час делайте.

Мессадж касался сугубо коммента Метакласса, что систему контроля версий важнее компилятора :)

[dmzlj.livejournal.com]

Конечно важнее. В проекте может быть пяток компиляторов, и вообще их как грязи, сегодня один, завтра другой, послезавтра вообще без него.

А VCS и системы тикетов --- это организация процесса, который долго и мучительно отлаживается, и с системы на систему не очень попрыгаешь. Особенно issue tracker-ов, которых вообще нормальных нет.

По поводу backup я не путаю. При работающем контроле версий мне никакой отдельный бэкап на компах не нужен, достаточно на серверах наладить автоматический процесс.

[psilogic.livejournal.com]

[ В проекте может быть пяток компиляторов, и вообще их как грязи, сегодня один, завтра другой, послезавтра вообще без него. ]

вообще без него - это как? ручками в бинарные коды переводить? :)

[ По поводу backup я не путаю ]

ну немножко было, чего уж там, будем считать, что это я вас запутал :) но теперь то все понятно?

[dmzlj.livejournal.com]

вообще без него - это как? ручками в бинарные коды переводить? :)

интерпретатор, например. Какой у PHP или питона компилятор?

[psilogic.livejournal.com]

ну вводная такова, что есть проект на C++. без контроля версий - можно, без трекера - тоже. даже без дебаггера можно (встаем в позу отладочной печати). без компилятора - никак.

[dmzlj.livejournal.com]

Система контроля версий очень слабо относится к тому, на чем проект. Причем здесь вообще на C++ он или нет? Если бы речь шла о том, что ничего нет, и надо выбирать, что написать --- компилятор, систему контроля версий или issue tracker --- такая постановка вопроса имела бы смысл. А так --- все есть, бери и пользуйся. И непонятно, как использование C++ оправдывает использование мертвой кривой системы контроля версий.

[blacklion.livejournal.com]

1. Как не способ? Благодаря таким мерам вы видите, что есть конфликт и просто исправляете его. Если прозевали, и какой-то файл оказался незакоммиченным, то исправите его чуть позже.
Да, но изменения могут быть согласованными вот по этим трём файлам. И если у вас есть момент когда ДВА файла с новым контентом УЖЕ в репозитории а третий — нет (потому что конфликт и вы пол-часа его исправляете) — это очень, очень плохо.

[psilogic.livejournal.com]

И не говорите, ужасть, просто ужасть! :)

Если серьезно, то длительная задержка - большая редкость, а короткая ни на ком не сказывается.