FreeBSD переходит с CVS на SVN

> Видимо они хотят это централизованно обслуживать.

Децентрализованные системы позволяют делать то же, что и централизованные и даже больше. Это больше можно использовать, а можно и не использовать, но лишним оно не будет.

> Кто хочет при этом распределённости, тот устанавливает SVK, синхронизируется и едет на год в глушь программировать.

Если отбросить мою нелюбовь к svk, то это никак не аргумент в пользу централизованных систем.

в svn нет бранчей? хм... а про что же эта глава руководства - http://svnbook.red-bean.com/en/1.1/ch04s02.html ?

тролле детектед?))

>> учи матчасть. в cvs есть и теги и бранчи.

> [...] В нём меньшее количество элементарных операций, реализующих тот же функционал.

Мусье не думал завязывать с веществами?

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

Эм. Меня похоже не так поняли.

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

В svn нет этих команд, в нём есть constant-time copying, позволяющий эти концепции эмулировать. Не нужно учить новых команд, не нужно их помнить, не нужно в них ошибаться. Достаточно понимать, что такое бранчи и теги на концептуальном уровне.

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

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

Прикольно.

>Есть такое понятие, как ортогональность системы. Если одна система меньшим числом элементарных действий реализует функционал, аналогичный тому, который реализует система с большим числом элементарных действий, первая ортогональнее второй. Ортогональность это, обычно, хорошо.

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

P.S. Для отсутствующей части мозга: поищите связь между ортогональностью, перепендикулярностью и тем, что вы нарисовали.

The Art of Unix Programming почитай на досуге, уважаемый нейрофизиолог.

Orthogonality is one of the most important properties that can help make even complex designs compact. In a purely orthogonal design, operations do not have side effects; each action (whether it's an API call, a macro invocation, or a language operation) changes just one thing without affecting others. There is one and only one way to change each property of whatever system you are controlling.

Your monitor has orthogonal controls. You can change the brightness independently of the contrast level, and (if the monitor has one) the color balance control will be independent of both. Imagine how much more difficult it would be to adjust a monitor on which the brightness knob affected the color balance: you'd have to compensate by tweaking the color balance every time after you changed the brightness. Worse, imagine if the contrast control also affected the color balance; then, you'd have to adjust both knobs simultaneously in exactly the right way to change either contrast or color balance alone while holding the other constant.

Первые два абзаца оттуда. И где тут количество операций и прочий бред?

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

>людям нужен готовый стабильный продукт, а не свестелко-перделка с огромным туду листом для красноглазых идиотов

И?

> darcs2 ещё не вышёл? Ы

Он наконец-то вышел... 7 апреля? Ах, Дэвид не рекомендует его для больших репозиториев (GHC, "Darcs 2.0.0 contains some performance regressions when running with large repositories")? Он его вообще пока никому не рекомендует? Ы

> Не стоит так нагло врать.

Ну что тебе сказать на это? ПНХ.

>Линус Т. говорил что SVN это беспомощное говно

После чего за год SVN'у заметно полегчало. А Линус говорил больше о применимости к разработке ядра.

все мифические неудобства от криых виндузячих рук. тянушихся коммитить в BSD

Это обсуждалось уже 1000 раз на лоре.
Обратите внимание, что Сабвершн популярнее всех распределённых систем вместе взятых.
Процитирцю себя http://www.linux.org.ru/view-message.jsp?msgid=2343225#2343813
DVCM нужен(по моему личному опыту), если у вас многоуровневый комит.
К примеру совсем дикие вьетнамцы комитят всё на сервера китайцам, котрым идусы отусорсят проекты, когда сами не успевают их делать. Потом китайцы убирают камменты на вьетнамском, заменя их на камменты на китайском и на какую-то хрень на языке, который они считают английским и коммитят это на идусские сервера. Индусы убирают каменты на китайском и заменяют их на каменты на английском, хинди, суахили и ещё примерно сотне живых языков. Так как китайского и той хрени, которую китайцы написали на латинскими буквани они не понимают, то читать это потом интересно и познавательно с любой точки зрения, кроме как с программистской. Потом всё это идёт на сервера оутсорсинговой конторы, которя добавляет туда красивые хедеры из каментов и пытается это запустить. Так как нихрена не работает, по этот комит заказчику не идёт или идет уже с изменениями, которые позволили проекту хотя бы запускаться.

Если это не ваш случай, то тот-же Subversion значительно удобнее. Следуйте принкипу KIS! Keep It Simple!

>нахуй cvs и svn, да здравствует Visual Studio Team Server

git рулит:D

>снес сегодня линукс. поставил винду. надо немного разобраться с интерфейсом. но вцелом - неплохо. даже удобнее КДЕ

troll detected %)

> Если это не ваш случай, то тот-же Subversion значительно удобнее.

Чем?

Как правильно сказал Ларри, Subversion может терять данные при каждом коммите.

>я перешел с семейных труселей на летние плавки. Ура ОпепСорцу!

все равно давать не будут

> Если одна система меньшим числом элементарных действий реализует функционал, аналогичный тому, который реализует система с большим числом элементарных действий, первая ортогональнее второй. Ортогональность это, обычно, хорошо.

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

Теги,бранчи и копии всё-таки разные штуки. Если мы эмулируем теги бранчами-листьями, без хвоста, а бранчи -- копиями, то далее, развивая эту концепцию, должен из коробки работать cherry-picking между копиями (также, как он должен работать между бранчами).

> Ну, было дело, еще какой-то неймфаг Линус Т. говорил что SVN это
> беспомощное говно, ну да какое нам дело до него.
Я так понимаю, при признесении сего имени всем положено присесть и
троекратно прокричать "Ку", одновременно посыпая голову пеплом?

Вышеозначенному Линусу Т., а так же анонимной группе поддержки, неплохо
бы выпить валерьянки и осознать, что не у всех работа заключается в
разборке коллекции патчей. Соответственно и критерии выбора могут быть
несколько отличными от критериев солнцеподобного. Принципиальная
возможность интеграции с Git и Mercurial для любителей, был одним из, к
примеру.

>Как правильно сказал Ларри, Subversion может терять данные при каждом коммите.
А можно поподробнее?

> Соответственно и критерии выбора могут быть несколько отличными от критериев солнцеподобного.

А по каким таким важным критериям Subversion выиграла? По моему опыту, она хуже Mercurial по практически всем параметрам (единственное - репозиторий можно поправить после коммита).

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

Ну например, "всё -- это файл" -- это ортогонально, да (с оговорками). Но концепции сокет, обычный файл, блочное устройство, объект -- разные, так что "любой файл -- объект, но не любой объект -- файл".

> Если это не ваш случай

Когда командой 2-3 человека делаете существенный патч - децентрализация - гораздо удобнее чем кидаться друг в друга патчами по e-mail. За несколько недель написали много всякой хрени в своем локальном репозитарии - поправили друг друга, довели все до ума, а потом уже беспокоите больших занятых дядек.

В svn надо все делать сразу и правильно - нельзя заглушек повставлять типа int get_random() { return 4; }

>>Как правильно сказал Ларри, Subversion может терять данные при каждом коммите.

> А можно поподробнее?

bitmover.com у меня не открывается, так что я изложу своими словами. Пусть у нас есть репозиторий с файлами a и b; два программиста делают svn co и начинают работать. Первый меняет файл a и делает svn ci; второй меняет файл b и делает svn ci _позже_ второго. В результате после второго коммита в репозитории имеем состояние, которое не соответствует рабочей копии второго прогораммиста на момент svn ci (в репозитории будет измененный первым файл a и измененный вторым фал b). После удаления этой рабочей копии информация утеряна навсегда.

Придумывание неприятных сценариев оставлено как упражнение читателю :)

Линус Тролльрвальдс, ага.

Не понял.
Есть 3 версии.
1. А0, Б0
2. А1, Б0
3. А1, Б1

Все 3 доступны.
Что потерялось?

> В результате после второго коммита в репозитории имеем состояние, которое не соответствует рабочей копии второго прогораммиста

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

1. А0, Б0 2. А1, Б0 3. А0, Б1

в репозитарии: A1, Б1

>bitmover.com у меня не открывается, так что я изложу своими словами. Пусть у нас есть репозиторий с файлами a и b; два программиста делают svn co и начинают работать. Первый меняет файл a и делает svn ci; второй меняет файл b и делает svn ci _позже_ второго. В результате после второго коммита в репозитории имеем состояние, которое не соответствует рабочей копии второго прогораммиста на момент svn ci (в репозитории будет измененный первым файл a и измененный вторым фал b). После удаления этой рабочей копии информация утеряна навсегда.

Вообще-то второму не разрешат сделать коммит, т.к. он не засинхронизировался с сервером.

http://www.opennet.ru/opennews/art.shtml?num=16277

Команда разработчиков Mozilla сообщает, что миграция проекта с CVS на Mercurial достигла стадии, когда уже можно отправлять код в новый репозиторий ( mozilla-central ).

> Вообще-то второму не разрешат сделать коммит, т.к. он не засинхронизировался с сервером.

Проверять лень, но что именно он не засинхронизировал?

В репозитории все 3 версии.

> Что потерялось?

А0 Б1 - состояние фиксируемой рабочей копии второго прогера.

> Проверять лень, но что именно он не засинхронизировал?

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

>> Проверять лень, но что именно он не засинхронизировал?

> свой рабочий каталог, который он хотел комитить

А если он коммитил один файл?

> А по каким таким важным критериям Subversion выиграла? По моему опыту,
> она хуже Mercurial по практически всем параметрам (единственное -
> репозиторий можно поправить после коммита).

Невозможность оbliterate - это основной недостаток. Законник с пистолетом, требующий переписать историю - к сожалению такое вполне может случиться.
Невозможность поддержки частичных checkout, когда нужно не всё дерево, а только конкретный файл или директорий.
Working Directory == Repository, многих это раздражает.

...
Там был довольно длинный список.

> Невозможность оbliterate - это основной недостаток

Хе, я так и думал %) А о стандартном трюке с использованием convert они не знают? O_o

> Там был довольно длинный список.

Где его можно посмотреть?

>> Что потерялось?
>А0 Б1 - состояние фиксируемой рабочей копии второго прогера.
Если он не дурак и работает в бранче, то оно никуда не потеряется.
Если дурак, то это надолго :)

>>> Проверять лень, но что именно он не засинхронизировал?

>> свой рабочий каталог, который он хотел комитить

> А если он коммитил один файл?

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

> Если он не дурак и работает в бранче, то оно никуда не потеряется.

Ну, ты назвал кучу прогеров дураками. Включая разрабов SVN, GCC, и т.д., и наверняка - включая людей из FreeBSD.

А личные бранчи - это как раз суть распределенных систем. Их можно создавать и в централизованных системах, но какой смысл? /me вужосе представляет каталог /branches крупной организации.

P.S. а если учесть корявую поддержку merging в SVN, еще неизвестно, кто дурак - тот, кто на персоналном бранче, или тот, кто на транке :D

Ээээ ...
На самом деле, большинство клиентов требуют синхронизации перед комитом. Тогда 2 программист просто обязан будет взять последнюю версию перед тем как залить Б2.
сломать проект комитом нерабочего файла можно, но, обрати внимание, никого, кроме сторонников Меркуриал это не волнует.

Если второму програмисту нужна работчая версия А0, Б1 и он не работает в бранче, то он дурак, вне зависимоти от того что при это он является одним из "разрабов SVN, GCC, и т.д., и наверняка - включая людей из FreeBSD.". Дурак это состояние мозга которое, к сожелению, не препятствует проникновению в ключевые проекты.

> На самом деле, большинство клиентов требуют синхронизации перед комитом

Стандартный CLI клиент - не требует.

> никого, кроме сторонников Меркуриал это не волнует.

Это волнует еще минимум 1 человека - Ларри МакВоя :)

> Если второму програмисту нужна работчая версия А0, Б1 и он не работает в бранче, то он дурак, вне зависимоти

Ну просто анекдот про д'Артаньяна :)

Откуда это пошло?

int get_random() { return 4; }

Несколько раз уже видел, с неизменным return 4

Черт, но как? Они же еще cvsup переписать не успели !

>> Невозможность оbliterate - это основной недостаток
>Хе, я так и думал %) А о стандартном трюке с использованием convert они не знают? O_o
Безусловно, о методе 'всё поломать и собрать обратно' мужики и не слышали. Даже те из FreeBSD team, что над Mercurial собственно работают. Ай поймал, ай молодца! А будет ли repo после соnvert тем же repo или _все_ люди, имеющие свои локальные бранчи и зеркала приплывут и будут вынуждены ресинхронизоваться по новой? У сильной криптографии, на которой построена идентификация изменений в Git и Hg есть и 'недостатки'.

> Где его можно посмотреть?
Архивы, wiki.

> Git rules them all.

Под альтернативные ОС не рулит...

>>Хе, я так и думал %) А о стандартном трюке с использованием convert они не знают? O_o

>Безусловно, о методе 'всё поломать и собрать обратно' мужики и не слышали

Ломать _всё_ не придется.

> Даже те из FreeBSD team, что над Mercurial собственно работают.

А такие есть? Кто? Про corecode и keltia знаю, но они ничего не пишут.

> Ай поймал, ай молодца!

Стараюсь!

> А будет ли repo после соnvert тем же repo

До коммита удаляемого файла - будет, AFAIK.

> _все_ люди, имеющие свои локальные бранчи и зеркала приплывут и будут вынуждены ресинхронизоваться по новой?

Отчасти - да. Но, насколько я знаю SVN, то же придется делать и ее пользователям.

> У сильной криптографии, на которой построена идентификация изменений в Git и Hg есть и 'недостатки'.

Я знаю. Однако, Bzr, к примеру, на ней не построен. Впрочем, он тормоззз...

>> Где его можно посмотреть?

>Архивы, wiki.

Какие именно?

> А0 Б1 - состояние фиксируемой рабочей копии второго прогера.

Собсно поэтому его заставляют синхронизироваться перед коммитом. Чтобы у него тоже образовалось А1 Б1, которое он мог бы проверить перед коммитом.

> его заставляют синхронизироваться перед коммитом

Кто и как?

> /me вужосе представляет каталог /branches крупной организации.

Вам представить страшно, а я это в живую видел... И даже на CVS приходилось это строить...