В FreeBSD анонсировано окончание поддержки CVS для портов

Ничего, здесь хватает откатывальщиков коммитов посредством мерджа.

Ежики плакались, кололись... но продолжают использовать Clang.

Можно подумать, что это clang виноват в ущербности cvs.

А как просишь показать типичный пример использования ими того же git, то оказывается, что дальше clone, pull, add и push дело не ушло.

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

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

а через пару лет уже от subversion будут отказываться?

Почему? В свне нет никакой модулы-3, и проект вполне живой. В 1.7, например, запилили общую sqlite-базу для всего репозитория вместо .svn в каждом подкаталоге.

Например, я майнейнер порта ports/x/wtf и мне нах.... не впились остальные 100500 портов. Я беру выкачиваю через svn только _свой_ порт и делаю с ним что хочу. Как мне в этом поможет git?

Если твой порт не имеет никаких зависимостей от других портов, то наверное git никак не поможет. Однако большинство софта всё же выполняется в определенном окружении и имеет зависимости, поэтому всё равно нужно иметь актуальный срез всех остальных портов в системе. А если всё равно приходится иметь актуальное состояние всех портов, то почему бы и не использовать для этих целей гит? Благодаря эффективному сжатию истории в гите, суммарный объём данных, который придётся вытащить по сети при первоначальном клонировании будет несущественно больше (а может и меньше) чем при вытаскивании всего лишь одной рабочей копии для subversion.

Разработчики могут упарываться чем угодно, просто cvsup, svnup, gitup или hgup не нужны.

С этим тоже согласен. Однако упоротые бсдшники не хотят пользоваться rsync по религиозным лицензионным соображениям, так что придётся им сначала изобрести «bsdsync».

А если всё равно приходится иметь актуальное состояние всех портов, то почему бы и не использовать для этих целей гит?

Зачем?

Благодаря эффективному сжатию истории в гите,

Да не нужна никому локальная история всех портов. А зависимости можно подтянуть в svn без выкачивания всего дерева.

В 1.7, например, запилили общую sqlite-базу для всего репозитория вместо .svn в каждом подкаталоге

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

Зачем?

Возможные причины я уже озвучивал выше. Суть в том, что для того чтобы воспользоваться всеми этими преимуществами придётся мириться с единственным недостатком - держать локально копию всей истории. Если бсдшникам это не нужно, ну что ж, пусть используют svn, меня этот факт мало волнует.

А зависимости можно подтянуть в svn без выкачивания всего дерева.

Т.е. всё таки придётся вручную искать порты-зависимости и подтягивать к ним апдейты из репы? Зачем, если можно сделать удиный git pull? :)

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

Это по прежнему можно, просто в локальной рабочей копии он все свои метаданные теперь хранит в единой директории .svn.

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

Суть в том, что для портов все эти преимущества не нужны вообще.

Т.е. всё таки придётся вручную искать порты-зависимости и подтягивать к ним апдейты из репы?

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

Зачем, если можно сделать удиный git pull?

Который утянет _всё_ в том числе ненужное и со всей историей. Для такой вещи как порты это неприемлемо.

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

главный недостаток git в том, что это непонятное угробище, созданное инопланетянами для инопланетян

...и их добровольных рабов.

Всё ещё впереди — надейся и жди!

google://Света_из_Иваново

Нах...я?

Например, чтобы перезапись подкаталога не убивала метаданные

А самый главный недостаток git в том, что это непонятное угробище, созданное инопланетянами для инопланетян.

Так и напиши: неосилил. Осилившие же видят, что принцип работы других VCS морально устарел

принцип работы других VCS морально устарел

Принцип работы Git цельнотянут с Monotone.

Возможно, не работал с последним. Читал, что во времена юности гита он тормозил, ну и Торвальдс C++-хейтер.

Это вообще Linux-way, сделать, потом подумать и переделать.

Во-первых, объясни как «новый принцип работы» dvcs поможет разработчикам портов. Во-вторых, объясни чем инопланетный гит лучше человеческого меркуриала, который построен на том же новом принципе работы, но в отличие от гита его не надо «осиливать».

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

Спасибо конечно, но я умею пользоваться svn.

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

Я так понимаю, на этом разумные аргументы закончились? Если бы бсдшники выбрали меркуриал, ты бы возражать не стал?

А самый главный недостаток git в том, что это непонятное угробище, созданное инопланетянами для инопланетян.

Ты уже два года ноешь на эту тему. Хотя отличий с гулькин хрен:

http://mercurial.selenic.com/wiki/GitConcepts

Мне лично уже давно по-барабану, hg или git, все равно вся разработка патчами идет.

Чем необходимость потратить пару месяцев на освоение git всему сообществу не аргумент? Как раз переход cvs->git требует сильной аргументации, а переезд cvs->svn для портов самоочевиден.

Хотя отличий с гулькин хрен:

http://mercurial.selenic.com/wiki/GitConcepts

Концептуально все DVCS на криптохешах одинаковы. И эта одинаковость значит с гулькин хрен.

Ну конечно. Мне, например крышу сносит от того, что checkout'ом в гите делается и апдейт сорцов и откат изменений, а для полного отката надо вызывать совершенно другую команду. Также нет нормальных outgoing/incoming, невменяемые сообщения об ошибках, ну и туева хуча разных раздражающих мелочей.

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

Стал бы, потому dvcs в данном случае как пятое колесо в телеге.

Мне, например крышу сносит от того, что checkout'ом в гите делается и апдейт сорцов и откат изменений, а для полного отката надо вызывать совершенно другую команду.

Гит просто дает работать с графом ревизий не заботясь о лишних абстракциях. checkout — передвинуть текущий указатель, reset — сделать ноду головой. То что у Линуса с фантазией плохо и он решил использовать знакомые слова вместо подходящих по семантике — от этого еще никто не умер, тысячи одинэсников, вон, тоже пытаются сначала на ангельском писать.

Также нет нормальных outgoing/incoming

Что значит нормальных? Ты так говоришь, как будто разницу с основной репой надо знать каждую минуту. У меня складывается впечатления что ты до сих пор болен svn.

То что у Линуса с фантазией плохо

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

Что значит нормальных?

Значит в одну _простую_ команду без шаманств.

Ты так говоришь, как будто разницу с основной репой надо знать каждую минуту

Как минимум когда делаешь pull/push

Значит в одну _простую_ команду без шаманств.

Для hg я сделал не одну команду для работы с патчами и ничо, не переломился. Алиасы есть и в гите.

Как минимум когда делаешь pull/push

Зачем, ради всего святого, можешь объяснить? Зачем проверять что прилетит с пулом? Ну прилетело, ну ребейзнулось, зачем это проверять до? А push? Тебя сразу завернут если твоя история не встает. Ничего не понимаю.

Если плохо с фантазией, то надо смотреть как сделано в аналогах.

Плохой танцор, обычно, не знает о своей проблеме.

Зачем проверять что прилетит с пулом?

Чтобы случайно не забрать говно. Это особенно актуально когда делаешь pull с репозитория коллеги.

А push?

Чтобы нерабочее говно случайно не отправить

checkout — передвинуть текущий указатель

Как минимум hg тоже умеет это (полагаю, что SVN тоже), _но_ в в нем (и SVN) есть и revert - чтобы человеку было удобнее.

reset — сделать ноду головой

Это так команда, которая благодаря --hard, --soft и --mixed становится 3 разными командами? %)

Ты так говоришь, как будто разницу с основной репой надо знать каждую минуту

Когда push не проходит, время узнавать разницу.

Чтобы случайно не забрать говно.

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

Чтобы нерабочее говно случайно не отправить

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

Когда push не проходит, время узнавать разницу.

git fetch && git log ..origin

Кишки наружу, да, зато нет лишних наслоений, полная прозрачность.

// Кстати, если не проходит push, просто делаю pull. Откатить тупо легче.

Ты не пользуешься mq

Ха. Скоро у нас будет вот такая игрушка: http://hg-lab.logilab.org/doc/mutable-history/html/

Видимо, говно не настолько случайное

Конечно. Система децентрализованная. Это на сервере может быть более менее порядок, а на машине коллеги может быть любая помойка. И делать pull с помойки без предварительного incoming может быть чревато.

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

Пользуюсь. Отправить нечто можно из-за ошибки, я люблю перестраховаться.

и SVN

Давай не будем говорить о логичности системы в которой обратный коммит делается через merge.

Это так команда, которая благодаря --hard, --soft и --mixed становится 3 разными командами? %)

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

Давай не будем говорить о логичности системы в которой обратный коммит делается через merge.

Эээ... щито?

Проще надо быть.

«Простой, как маленький ЛенинЛинус Торвальдс» (ц)

Отправить нечто можно из-за ошибки, я люблю перестраховаться.

Гм, каким образом? С фазами вообще себя чувствуешь как и христа за пазухой.

Гм, каким образом?

Да как угодно можно случано накосячить. Закоммитить не то, недокоммитить, закоммитить лишнее. mq от этого не спасает, можно перед pull забыть сделать qpop и всё это пролезет на сервер

Эээ... щито?

«hg backout #», «git revert #» в свн будет как «svn merge -c -#».

можно перед pull забыть сделать qpop и всё это пролезет на сервер

Суровый у вас pull. Даже на сервер может запушить.

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

«hg backout #», «git revert #» в свн будет как «svn merge -c -#».

В Mercurial результатом backout является отдельная голова, которую нужно смержить. Насчет Git не знаю, но сильно подозреваю аналогичную ситуацию.

фазы, очень рульная штукенция, единственно чего реально не хватает в гите.

А язык запросов в Git есть?

http://selenic.com/hg/help/revsets

Суровый у вас pull. Даже на сервер может запушить.

Имел ввиду push :)

Если это опечатка, то почитай про фазы

Почитаю. Но 100% рабочего решения нет и быть не может. Видишь, даже сейчас хотел написать push, а написал pull :)

Можно ограничится только снапшотом или срезом версии.

Legit?

В Mercurial результатом backout является отдельная голова

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

но сильно подозреваю аналогичную ситуацию.

По умолчанию в гите просто создается коммит. SVN же тупо загрязняет рабочую копию, собстна как простой merge.

Проще если команда соответсвует использованию, а не реализации. Интерфейс отдельно, кишки отдельно. В случае с git-ом, даже для минимального использования надо знать подробности релаизации. Это неправильно.

Legit?

И? Неосиляторы mq пытаются откреститься бранчами?

В случае с git-ом, даже для минимального использования надо знать подробности релаизации.

Ты же не имел в виду под «подробностями реализации» исходники гита? Верно?

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