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

[metaclass]

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

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

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

Comments

[dmzlj.livejournal.com]

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

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

[metaclass.livejournal.com]

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

[dmzlj.livejournal.com]

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

Т.е. если соблюдать правило, что публичные коммиты должны быть крупнозернистыми, осмысленными и относительно mainline, то проблем не возникает.

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

Revision X
---
int jopa = 0l

Revision X+1
---
int ijopa = 0l


Revision X+2
---
// inner loop caunter
int counter = 0;

Revision X+3
---
// inner loop counter
// int inner_loop_counter = 0;

Опять же, с бранчами пропадает необходимость в code freeze, которые приходится объявлять на недосистемах типа CVS.

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

[psilogic.livejournal.com]

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

Да нет, все нормально, несколько элементарных правил - и никакого бардака.

[dmzlj.livejournal.com]

У нас есть такие приборы... Озвучьте их, что ли.

[psilogic.livejournal.com]

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

Если бы вы сказали, какой рода бардак вам видится в такой ситуации, я бы вам привел конкретные меры, позволяющие его избежать.

[dmzlj.livejournal.com]

Неатомарные коммиты, например. Отличный источник бардака всегда был

Потеря кода при и отсутствие возможности отмотки назад при разработке, при редких коммитах (коммитить только работающий код)

Гиморой с рефакторингом (переименования)

Наличие смешных code freeze, как воркараундов вокруг убогости инструментария

[psilogic.livejournal.com]

[ Неатомарные коммиты, например. Отличный источник бардака всегда был ]

Что такое неатомарные коммиты? Я так понял, это серия нескольких связанных коммитов... но как они ведут к бардаку?

[ Потеря кода при и отсутствие возможности отмотки назад при разработке, при редких коммитах (коммитить только работающий код) ]

Решение проблемы: коммитить сколь угодно часто, но не коммитить тот файл, который включает сырой код в общую сборку. В результате на вашем компе собирается сырой код, на остальных - старый, стабильный.

[ Гиморой с рефакторингом (переименования) ]

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

[ Наличие смешных code freeze, как воркараундов вокруг убогости инструментария ]

Что такое code freeze?

[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 потом обратно - это не проблема.

[metaclass.livejournal.com]

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

[psilogic.livejournal.com]

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

[blacklion.livejournal.com]

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

[blacklion.livejournal.com]

Просто удаляем файл и закоммичиваем новый.
Т.е. вы даже про repocopy не знаете? :)

[psilogic.livejournal.com]

[ Т.е. вы даже про repocopy не знаете? :) ]

Да куда нам, мы ж люди темные :)

[kurilka.livejournal.com]

Про работу с бранчами вот это мне понравилось - http://nvie.com/git-model

[nivanych.livejournal.com]

Пасиб.
Мне с гитом, видимо, придётся сталкиваться,
надо бы потихоньку смотреть матчасть.

[kurilka.livejournal.com]

Ты ведь на hg сидел вроде?
Производственная необходимость?

[nivanych.livejournal.com]

Ага, на hg.
Нет, пока необходимости нет, но есть вероятность, что она появится.
Да и статейка неплохая, хоть и слишком git-специфична, как мне показалось.

[kurilka.livejournal.com]

Ну не знаю, что там специфичного? По сути же про более-менее логичное разделение веток

[nivanych.livejournal.com]

Логичное разделение веток, да.
Поэтому мне статья и понравилась ;-)
Про git-специфичное, это я про примеры.