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

> Кто и как?

Уже понял, в чем проблема :-).

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

"Возьмем произвольное целое число 9" (C)

@Legioner,

В SVN есть и тэги, и ветки.

>> Git rules them all.

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

А какие проблемы с git на Mac и Solaris ?

>> int get_random() { return 4; } > Откуда это пошло?

Наверное отсюда: http://imgs.xkcd.com/comics/random_number.png

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

Быдлокодить тоже надо аккуратно - вставлять в таких местах метки типа NOTE, BUG и другие, оговоренные с другими участниками проекта и занесенными в wiki, а затем грепать исходники по поводу недоделанных или неправильно работающих мест.

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

Читал Эрика Рэймонда "Собор и Базар" о технологии разработки сложных программных систем?

Так это ответ на твоё сообщение:
http://www.opennet.ru/openforum/vsluhforumID3/42153.html#11
>>Пока не поздно следует одуматься. Недавно в новостях было, что сам автор
>>SVN критиковал текущую структуру и говорил, что будущее за децентрализованными системами
>>управления исходным кодом. А SVN лишь попытка решить некоторые проблемы CVS
>>не меняя при этом основных принципов.
>>Посмотрели бы лучше в сторону Git или Mercurial.

>Не-а. FreeBSD -- это Cathedral, а не Bazaar. Для него Subversion -- самое то. А git или hg в таком случае -- просто тупая трата дискового места на машинах разработчиков.


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

> в tla целую "теорию патчей" навертели

tla мертв. "Теория патчей" - это DARCS.

> git или hg в таком случае -- просто тупая трата дискового места на машинах разработчиков.

Репозиторий Mercurial + рабочая копия часто занимают меньше места, чем одна рабочая копия SVN.

>> Даже те из FreeBSD team, что над Mercurial собственно работают.
> А такие есть? Кто? Про corecode и keltia знаю, но они ничего не пишут.
А кто как не Olivier продвигал Hg? На вопрос по поводу obliterate отвечал тоже он.

>> А будет ли repo после соnvert тем же repo
>До коммита удаляемого файла - будет, AFAIK.

А как ты думаешь, законник с пистолетом заявится сразу после коммита или всё-же некоторое время спустя? Скажем, годы спустя. И много будет радости от такого вот AFAIK?

> Отчасти - да. Но, насколько я знаю SVN, то же придется делать и ее
> пользователям.
svn предоставляет принципиальную возможность прямой модификации базы данных, поэтому операцию можно провести безболезненно для всех клиентов, которые не смотрям прямо на затронутое изменение. В этом смысле SVN ничем принципиальным не отличается от CVS.

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

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

Угу. Git становится меннее убогим и более дружелюбным, DARCS и Bzr быстрее. И всё это счастье наступит завтра. Ждём-с.

Когда счастье таки подкрадётся, svn co всеми своими недостатками предоставит прекрасную стартовую базу с полной историей. Двери никто не заколачивает.

>Какие именно?
А пирожки за тебя тоже я есть буду?

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

>А кто как не Olivier продвигал Hg? На вопрос по поводу obliterate отвечал тоже он.

Не припомню, чтобы он "работал над Mercurial", но ладно.

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

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

>А как ты думаешь, законник с пистолетом заявится сразу после коммита или всё-же некоторое время спустя? Скажем, годы спустя. И много будет радости от такого вот AFAIK?

Я думаю, что радости будет мало в любом случае. Насколько хуже была бы ситуация с Mercurial - не знаю. Ты тоже не знаешь.

Впрочем, если во FreeBSD решили, что им лучше ориентироваться на "законников с пистолетами" - что ж, с последствиями иметь дело именно им.

> А пирожки за тебя тоже я есть буду?

Да, кушай на здоровье.

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

А OpenSolaris - тоже зоопарк?

> Репозиторий Mercurial + рабочая копия часто занимают меньше места, чем
> одна рабочая копия SVN.
A один репозиторий и Х рабочих копий? Да с полной историей? Не всё так просто...

Рабочая копия svk вообще никаких служебных файлов не держит. Все на svk, hg в топку?

>> Репозиторий Mercurial + рабочая копия часто занимают меньше места, чем одна рабочая копия SVN.

> A один репозиторий и Х рабочих копий? Да с полной историей?

"Полная история" одна и та же в пределах одной ФС, так что для нескольких рабочих копий Mercurial еще экономнее, чем для одной.

> Не всё так просто...

Просто для справки: я пользователь Mercurial с версии 0.7, пользователь SVN с версии 0.14 по 1.2.x.

> Рабочая копия svk вообще никаких служебных файлов не держит. Все на svk, hg в топку?

SVK хранит столько же информации, сколько и hg, только зеркало репозитория лежит не в каталоге .svk рабочей копии, а где-то в ~/.svk (ага, я пользовался и svk тоже, но деталей уже не помню).

Это, конечно, хорошо.. Однако, жаль, что не синхронно с портами.. И, к тому же, можно было попробовать git или mercurial.

а ещё лучше параллельно.. хотя, это и потребовало бы больших затрат ресурсов..

Что вы тут разорались: "git"... "mercurial"...? Известны нам их плюсы, но выдайте мне плагины под GUI, под Eclipse, под Винду и т.д., тогда я их продвигать буду. Дальше SVN и периодического SVK никуда уйти не удалось.

> но выдайте мне плагины под GUI, под Eclipse, под Винду

Ну есть плагин Mercurial для Eclipse (даже 2 8)), есть TortoiseHG, разрабатывается интеграция с файл-менеджерами Линукса. Что еще нужно?

> выдайте мне плагины под GUI, под Eclipse, под Винду и т.д., тогда я их продвигать буду

FreeBSD пишется в Эклипсе, да еще и под виндой?

Ага я тоже аж подпрыгнул :)

Я лично думаю SVN выбрали именно потому что потом будет легче упрыгать дальше. Куда - не знаю, git не юзал - судить не могу, hg - хорош. Будем посмотреть.

Может фряха и не умрет сразу...

Зависит от их workflow, но то, что SVN ненужное, тормозное, недоделанное и опасное даже в умелых руках поделие - факт. Попробуйте поработать в проекте от 10к файлов по feature branching workflow и огребите на обратном мердже в транк (а ведь этот workflow описан как возможный и чуть ли не рекомендуемый в svn-book)...

А еще блокирующий code review, а еще каталог /branches на десятки бранчей, а еще постоянно помнить про 4-е измерение при merging, branching, renaming, deleting, а еще долбаные тормоза при chekin, checkout, update, охрененные размеры локальной копии бранча и нехилая нагрузка на дисковую подсистему при работе с ней...

PS: Все. дальше следует непереводимая игра слов и буря эмойций, способная причинить вред в радиусе 100 метров всему живому...

PPS: Извините, наболело

Эх, где опенсурсный клон clearcase? :\

clearcase - самая жуткая из VCS которые я видел. Отсутсвие атомарных комитов и идеология check-out check-in уже достаточны чтобы не вспоминать об этом поделии. Но так оно корпоративный стандарт - то мы поставили hg в команде и я раз в неделю синхронизируюсь с clearcase чтобы мучился только 1 человек, трачу 2-3 часа на merge, вместо 5 минут в hg - к отчетам прилагаю commit emails из hg потому что из clearcase все равно ничего понять невозможно. Единственная причина которую я могу придумать почему ее ползуют - несолидно в толстой организации пользовать бесплатный софт - поэтому и взяли clearcase который стоит >$4000 за коннект + плюс штат админов потому как каждый день надо разруливать массу проблем. А теперь все его пользователи кого я знаю каждый день его матерят, но продолжают жрать кактус.

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

И кому-то это дерьмо (извините, но другого эпитета оно не заслуживает) нравиться?

>Попробуйте поработать в проекте от 10к файлов по feature branching workflow и огребите на обратном мердже в транк (а ведь этот workflow описан как возможный и чуть ли не рекомендуемый в svn-book)...

Да, есть такое дело - feature branching workflow нужно использовать только для очень крупных фич (типа переход на новые системы, лежащие в самой основе программы, который требует изменений в половине файлов программы). Тогда время на svn switch и создание новой рабочей копии (чтобы смотреть почему в исходной проге не было тонны появившихся багов) будет небольшим по сравнению с разработкой фичи.

>Ну есть плагин Mercurial для Eclipse (даже 2 8))

Оно уже рабочее? Какой, кстати, второй, я только http://www.vectrace.com/mercurialeclipse/ знаю. Пару месяцев назад было не очень рабочее, пара операций в Eclipse типа переименовывания пакаджей/классов и ему снесло крышу.

>> Ну есть плагин Mercurial для Eclipse (даже 2 8))

> Какой, кстати, второй, я только http://www.vectrace.com/mercurialeclipse/ знаю

Да я ХЗ, в мэйл-листе проскочил анонс.

> Пару месяцев назад было не очень рабочее

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

> I fully expect this to change over time. At some point, git (or the next latest and greatest thing) will be compelling and will either support our models or we'll have changed ours. We'll be in a heck of a lot better shape for switching with svn as a starting point than with cvs.

> It has just been made significantly easier to prove your point. Now go do it. Well, in a few days when we have public infrastructure, that is. :) FWIW, we'll probably even offer a publically reachable git server that folks can clone from to make it easier still.

Ыыы... http://docs.FreeBSD.org/cgi/mid.cgi?e7db6d980806040021od995007y9de14ba04f0717df

public accessable git server... ХОТЕТЬ!

ps, http://people.freebsd.org/~peter/svn_notes.txt

> we'll probably even offer a publically reachable git server that folks can clone from to make it easier still.

Интересно, как они это объяснят злому законнику с пушкой %)

>А OpenSolaris - тоже зоопарк?

Плохой закос под линукс? :)

> I fully expect this to change over time. At some point, git (or the next latest and greatest thing) will be compelling and will either support our models or we'll have changed ours. We'll be in a heck of a lot better shape for switching with svn as a starting point than with cvs.

"Я серьёзно ожидаю что всё это постепенно изменится. В какой то момент git (или другая наипоследняя и наикрутейшая штучка) привлечёт наше внимание и либо она будет поддерживать наши модели [разработки?] либо мы поменяем их. Но по любому - мы будем в чертовски лучшей позиции для перехода [на неё] с svn'ом чем с cvs в качестве стартовой точки."

Внятная, сбалансированная _не_ фанатско-красноглазая позиция. За что и люблю этот проект :) А вы тут нафлудили ни о чём ...

GR.

> Внятная, сбалансированная _не_ фанатско-красноглазая позиция. За что и люблю этот проект :) А вы тут нафлудили ни о чём ...

позиция внятная, хотят избавиться от CVS с малым количеством пролитой крови... непонятен только страх перед distributed VCS, описанный в http://wiki.freebsd.org/VCSWhy

> git/hg make it very easy to take stuff offline. All the good aspects of that are well documented, and they are very good points. But the bad thing is that we undo some of the good that we've achieved by getting stuff off people's laptops and into a more public arena (like p4). Encouraging the taking of stuff further offline is going in the wrong direction for *us*. If anything, we need to make it easier for people to get stuff to us and in the tree in some form.

"But the bad thing...". Заставлять людей push'ить код на центральный сервер это Good Thing (TM)? DVCS просто *позволяют* хранить и обмениваться кодом в branch'ах НЕ ТОЛЬКО через одну точку соприкосновения, например svn.freebsd.org, но и минуя ее.

Мне кажется, скорость разработки возрастет в разы, если они перейдут на DVCS, т.к. порог к началу hacking'а будет сброшен почти до невидимости. А не как сейчас, нужно конвертить репозиторий или иметь права commit'а в svn (p4/cvs), чтобы начать экспериментальную ветку.

Ну вот видишь - это все про модель разработки. Bazaar\Cathedral. Решаться поменять - перейдут еще на что то.

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

Это точно. Достал уже merging в svn. :(