LINUX.ORG.RU

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

 , , ,


0

2

28 февраля 2013 года заявлено как дата, после которой дерево портов FreeBSD более не будет экспортироваться в CVS.

Это приведет к тому, что перестанут работать обновления дерева портов через CVS, cvsup и csup, к которым пользователи FreeBSD привыкли за многие годы использования этой системы. Всем пользователям рекомендуется перейти на обновление дерева портов через portsnap или subversion до указанной даты.

В качестве основной причины указывается крайняя сложность поддержки работы Ezm3 (компилятора, при помощи которого собирается cvsupd/cvsup) на архитектуре amd64 и сборки этого компилятора при помощи Clang.

>>> [HEADS-UP] Announcing the end of port CVS



Проверено: JB ()
Последнее исправление: sergv (всего исправлений: 1)

Ответ на: комментарий от wxw

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

baverman ★★★
()
Ответ на: комментарий от wheel

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

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

annulen ★★★★★
()
Ответ на: комментарий от r_asian

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

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

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

annulen ★★★★★
()
Ответ на: комментарий от niXman

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

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

annulen ★★★★★
()
Ответ на: комментарий от Reset

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

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

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

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

SKYRiDER ★★★
()
Ответ на: комментарий от SKYRiDER

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

Зачем?

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

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

Reset ★★★★★
()
Ответ на: комментарий от annulen

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

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

r_asian ★☆☆
()
Ответ на: комментарий от Reset

Зачем?

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

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

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

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

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

SKYRiDER ★★★
()
Ответ на: комментарий от SKYRiDER

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

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

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

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

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

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

Reset ★★★★★
()
Последнее исправление: Reset (всего исправлений: 1)
Ответ на: комментарий от SKYRiDER

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

Reset ★★★★★
()
Ответ на: комментарий от Reset

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от r_asian

Нах...я?

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

annulen ★★★★★
()
Ответ на: комментарий от Reset

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

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

annulen ★★★★★
()
Ответ на: комментарий от tailgunner

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

annulen ★★★★★
()
Ответ на: комментарий от Reset

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

u42
()
Ответ на: комментарий от annulen

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

Reset ★★★★★
()
Ответ на: комментарий от Reset

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

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

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

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

SKYRiDER ★★★
()
Ответ на: комментарий от Reset

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

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

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

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

baverman ★★★
()
Ответ на: комментарий от SKYRiDER

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

u42
()
Ответ на: комментарий от baverman

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

Reset ★★★★★
()
Ответ на: комментарий от SKYRiDER

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

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

Reset ★★★★★
()
Ответ на: комментарий от Reset

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

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

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

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

baverman ★★★
()
Последнее исправление: baverman (всего исправлений: 1)
Ответ на: комментарий от baverman

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

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

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

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

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

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

Reset ★★★★★
()
Ответ на: комментарий от Reset

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

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

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

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

baverman ★★★
()
Ответ на: комментарий от Reset

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

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

baverman ★★★
()
Ответ на: комментарий от baverman

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

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

А push?

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

Reset ★★★★★
()
Ответ на: комментарий от baverman

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

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

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

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от Reset

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

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

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

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

baverman ★★★
()
Ответ на: комментарий от tailgunner

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

git fetch && git log ..origin

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

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

baverman ★★★
()
Последнее исправление: baverman (всего исправлений: 1)
Ответ на: комментарий от baverman

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

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

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

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

Reset ★★★★★
()
Ответ на: комментарий от tailgunner

и SVN

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

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

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

baverman ★★★
()
Ответ на: комментарий от baverman

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

Эээ... щито?

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

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

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от Reset

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

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

baverman ★★★
()
Ответ на: комментарий от baverman

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

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

Reset ★★★★★
()
Последнее исправление: Reset (всего исправлений: 1)
Ответ на: комментарий от Reset

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

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

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

baverman ★★★
()
Ответ на: комментарий от baverman

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от baverman

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

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

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

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

Reset ★★★★★
()
Ответ на: комментарий от unC0Rr

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

Trieforce
()
Ответ на: комментарий от tailgunner

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

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

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

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

baverman ★★★
()
Ответ на: комментарий от baverman

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

u42
()
Ответ на: комментарий от Trieforce

Legit?

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

baverman ★★★
()
Ответ на: комментарий от u42

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

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

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

baverman ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.