Python-сообщество

При том, что нам не нужна РАСПРЕДЕЛЕННАЯ система контроля версий. Вполне устраивает централизованная. Но без блокиковок - это важно, намучались…
И ветки мы делаем очень редко.
“Единый” - наверное, я очень неудачно высказался.

gvim может показать и раскрасить отличия, к тому же у него в комплекте есть утилита diff

Отредактировано (Июнь 22, 2007 11:02:53)

Андрей Светлов
При том, что нам не нужна РАСПРЕДЕЛЕННАЯ система контроля версий. Вполне устраивает централизованная. Но без блокиковок - это важно, намучались…
И ветки мы делаем очень редко.
“Единый” - наверное, я очень неудачно высказался.

Я не представляю себе эффективную работу без веток. Даже в CVS я их пользовал очень много.

-Total Commander
-TortoiseIDiff из TortoiseSVN
-Araxis Merge

bialix

Андрей Светлов
При том, что нам не нужна РАСПРЕДЕЛЕННАЯ система контроля версий. Вполне устраивает централизованная. Но без блокиковок - это важно, намучались…
И ветки мы делаем очень редко.
“Единый” - наверное, я очень неудачно высказался.

Я не представляю себе эффективную работу без веток. Даже в CVS я их пользовал очень много.

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

dyno

bialix

Андрей Светлов
При том, что нам не нужна РАСПРЕДЕЛЕННАЯ система контроля версий. Вполне устраивает централизованная. Но без блокиковок - это важно, намучались…
И ветки мы делаем очень редко.
“Единый” - наверное, я очень неудачно высказался.

Я не представляю себе эффективную работу без веток. Даже в CVS я их пользовал очень много.

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

поскольку “ветки в svn” – понятие относительное, то чувствую, что вы не понимаете о чем я.

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

Правильно-неправильно – понятие относительное. Это больше стиль работы. Величина коллектива тут тоже не играет значения.

http://divmod.org/trac/wiki/UltimateQualityDevelopmentSystem
Просто для примера – это не мой текст, но показательно, что половина текста посвящена объяснению что такое ветки и почему надо использовать ветки в svn. И это тем более показательно, что это очень много говорит об слабостях концепции веток в svn. Я не наезжаю, нет.

bialix
http://divmod.org/trac/wiki/UltimateQualityDevelopmentSystem
Просто для примера – это не мой текст, но показательно, что половина текста посвящена объяснению что такое ветки и почему надо использовать ветки в svn. И это тем более показательно, что это очень много говорит об слабостях концепции веток в svn.

Прочитал. Рвзница в том, что у них есть формальный процесс review.
У нас в силу малочисленности комманды и работы в одном офисе review происходит гораздо проще. Я наблюдаю процесс постоянно и перед коммитом просматриваю изменения на машине разработчика.
Ошибок получается мало и их стоимость незначительна. Поэтому так и живем :)

Андрей Светлов

bialix
http://divmod.org/trac/wiki/UltimateQualityDevelopmentSystem
Просто для примера – это не мой текст, но показательно, что половина текста посвящена объяснению что такое ветки и почему надо использовать ветки в svn. И это тем более показательно, что это очень много говорит об слабостях концепции веток в svn.

Прочитал. Рвзница в том, что у них есть формальный процесс review.

Обзоры кода обязательно требуют выделения изменений в ветки. Но если внимательно посмотреть тот документ, то перечисляется еще очень много плюсов веток, безотносительно к тому есть обзоры или нету. Из всего раздела Why Branches (http://divmod.org/trac/wiki/UltimateQualityDevelopmentSystem#WhyBranches) только один пункт относится собственно к code review, остальные 8 как бы полезны и сами по себе. Особенно keep trunk working :-)