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)

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

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

тоже верно, + gc не удаляет потерянные коммиты младше двух недель. Но лучше не доводить до такого :)

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

Похоже на какое-то шаманство. Работа с именованными патчами в mq гораздо более интуитивно понятна, да и qpush'ить их можно в произвольном порядке.

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

Долгота написания важна для программ однодневок и их авторов.

Troll harder, babe.

Хочешь ворваться на рынок - можешь использовать и не C. Хочешь на нем удержаться - C без вариантов.

Firefox, Chrome и Eclipse смотрят на тебя с непониманием.

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

Сделай первый патч последним, отредактируй (e), и git rebase --continue

А потом, чтобы наложить поверх патчи, начиная со второго?

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

Всё дерево качается только в первый раз (причем, текущее). Далее только патчсеты.

Понел, не знал, буду знать. Но с cvsup'ом они зря так. Всё равно же дерево исходников им обновлять.

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

Долгота написания важна для программ однодневок и их авторов.

Troll harder, babe.

Ну так скажи, о чем новость?

Хочешь ворваться на рынок - можешь использовать и не C. Хочешь на нем удержаться - C без вариантов.

Firefox, Chrome и Eclipse смотрят на тебя с непониманием.

Исключения есть везде.

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

Я вот понимаю, что тот язык что нравится мне внимания не дсотоин и это просто хобби, а делать надо на C.

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

Понел, не знал, буду знать. Но с cvsup'ом они зря так. Всё равно же дерево исходников им обновлять.

Уже нет. Рекомендовано вообще freebsd-update пользоваться. И посмотри, какой метод обновления идет первым пунктом:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html...

sergv
() автор топика
Ответ на: комментарий от IPR

Всё равно же дерево исходников им обновлять.

уже нет. тег RELENG_9, то есть 9-STABLE, — это последний cvs тег. теперь только svn. тега для 9.1-RELEASE (RELENG_9_1) не будет.

мейлинг лист полезно читать: http://docs.freebsd.org/cgi/mid.cgi?1345729674.52121.4.camel

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

Перечитай новость, что бы понять. Да ты и сам все понимаешь

Конечно. И вывод из новости - «старайтесь не писать базовые вещи на всякой эзотерике». Не более.

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

Конечно. И вывод из новости - «старайтесь не писать базовые вещи на всякой эзотерике». Не более.

В замшелом 2004-м (когда amd64 только появилась как архитектура freebsd) году автору предложили (в шутку) переписать cvsup на хаскеле ;-)

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

Конечно. И вывод из новости - «старайтесь не писать базовые вещи на всякой эзотерике». Не более.

Кхм... с такой формулировкой согласен. Не придерешься.

Думаю, разночтения будут только в понятии «базовый» и «эзотерика». Но это субъективные детали.

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

Думаю, разночтения будут только в понятии «базовый» и «эзотерика»

«Базовый» - это «может понадобиться на минимальной системе».

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

freebsd-update уже давно запилили, там, вроде, в том числе и src-all можно вытягивать (хотя, тут врать сильно не буду).

Я тоже обновляюсь из freebsd-update, но ядро предпочитаю своё. А про вытянуть src-all f.-u. не слыхал.

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

уже нет. тег RELENG_9, то есть 9-STABLE, — это последний cvs тег. теперь только svn. тега для 9.1-RELEASE (RELENG_9_1) не будет.

Жесть. А в базовую систему что-нибудь типа svnup включат? А то впадлу всякую гадость из портов ставить.

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

Рекомендовано вообще freebsd-update пользоваться.

И каким образом самосборное ядро обновлять не прибегая к исходникам? :)

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

А в базовую систему что-нибудь типа svnup включат?

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

svnup еще никто не написал, так что только devel/subversion.

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

А потом, чтобы наложить поверх патчи, начиная со второго?

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

У тебя есть последовательность патчей 1-2-3-4-5, 5 - верхний. Если тебе нужно внести исправления в 1, а потом наложить сверху все остальные, ты делаешь git rebase -i HEAD~5, ставишь е для 1, правишь его, потом набираешь git rebase --continue, и сверху накладываются 4 оставшихся патча. По-моему, все предельно просто.

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

делаешь git rebase -i HEAD~5, ставишь е для 1, правишь его, потом набираешь git rebase --continue, и сверху накладываются 4 оставшихся патча. По-моему, все предельно просто.

Да, Ъ git-way.

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

А почему бы не включить svn целиком, лицензия у него «правильная»

я не видел обсуждений, если они и идут где-то. читаю только questions@ и stable@.

он вообще-то тяжелый. по крайней мере, собранный с дефолтными опциями

Information for subversion-1.7.5:

Depends on:
Dependency: expat-2.0.1_2
Dependency: pkgconf-0.8.7_2
Dependency: sqlite3-3.7.13
Dependency: gdbm-1.9.1
Dependency: db42-4.2.52_5
Dependency: libiconv-1.14
Dependency: gettext-0.18.1.1
Dependency: neon29-0.29.6_4
Dependency: apr-1.4.6.1.4.1_1

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

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

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

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

rebase -i показывает хэши и заголовки коммитов.

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

Слава богу, есть stgit и про rebase -i можно забыть как про страшный сон.

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

Да, Ъ git-way.

Вполне обычный интерактивный rebase, ничего хитрого в нём нет - достаточно попробовать один раз и в будущем вопросов не возникнет.

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

Может ты сначала попробуешь, а потом будешь высказывать своё недовольство «кривым» гитом? После запуска rebase -i в окне редактора ты увидишь сокращённые хеши коммитов вместе с их заголовками (первыми строками комментариев к коммитам), это вполне наглядно.

P.S. Уже который год вы с tailgunner'ом крутите здесь одну и ту же пластинку, ну надоело же. В этом топике именно вы являетесь самыми неадекватами - работая только с меркуриалом и попросту не зная и не понимая многих базовых операций в гите, вы тем не менее упорно продолжаете его осуждать. Иногда это бывает по делу, но чаще всего это абсолютно нерелевантные замечания, вызванные непониманием гита и желанием чтобы в нём было всё так, как сделано в знакомом (для вас) и уютненьком меркуриале. Этим самым вы напоминаете тех самых гитхабовских хомячков, которых так люто ненавидите.

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

btw, тоже самое можно сказать про поп-пуш возню со стеком.

+1. И вообще, mercurial далеко не так прост и интуитивно понятен, как этого хотят его фанатики. Многие вещи в нём делаются ничуть не проще, чем в гите, и во многих случаях требуют дополнительных параметров командной строки (сравните хотя бы http://mercurial.selenic.com/wiki/GitConcepts).

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

Вполне обычный интерактивный rebase, ничего хитрого в нём нет

Никто и не говорил, что в нем есть что-то хитрое. Просто это до смешного неудобно.

Может ты сначала попробуешь, а потом будешь высказывать своё недовольство «кривым» гитом?

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

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

Нет «базовых операций гита» - есть операции, общие для семейства VCS и DVCS. Просто в git они замаскированы гит-специфичными заклинаниями

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

btw, тоже самое можно сказать про поп-пуш возню со стеком.

Можно, если не хочется признавать очевидного. Но quilt, mq и stgit будут смотреть на вас с легкой грустью.

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

Нет «базовых операций гита» - есть операции, общие для семейства VCS и DVCS. Просто в git они замаскированы гит-специфичными заклинаниями

Да, есть такое, но таких операций не уж много (тем более среди базовых повседневных действий), а после прочтения мануала они становятся вполне понятны. Более того, после того как человек разберётся с основами - обычно наступает понимание того что гит на самом деле очень прост и логика его работы тривиальна и легко предсказуема, разве что «сахара» в некоторых местах не хватает.

P.S. Не смотря на то, что есть операции общие для всех VCS, начать пользоваться меркуриалом не читая документации всё равно не удастся, ну никак. И это даже не углубляясь в более продвинутые вещи, типа MQ (где аналоги «в семействе VCS»? quilt не в счёт). Так почему ненависть праведного лоровца всегда обрушивается исключительно на git?

P.S.S. Если уж заговорили о простоте UI, то среди всех DVCS однозначно самый простой и традиционный по набору команд - Bazaar, но его на лоре почему-то никто не хвалит. :)

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

Не смотря на то, что есть операции общие для всех VCS, начать пользоваться меркуриалом не читая документации всё равно не удастся, ну никак.

Знаешь, по каким источникам я учился пользоваться Mercurial? По статьям о BitKeeper (и, конечно, я знал SVN).

И это даже не углубляясь в более продвинутые вещи, типа MQ (где аналоги «в семействе VCS»? quilt не в счёт)

Как это не в счет? quilt - это как гоголевская «Шинель», из которой вышла вся русская литература %) Нет, серьезно - quilt реально влиятельная система. Фраза Мортона «your output is patches» - наверное, самое важное для понимания распределенной разработки (а может, и разработки вообще).

почему ненависть праведного лоровца всегда обрушивается исключительно на git?

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

Bazaar, но его на лоре почему-то никто не хвалит. :)

Потому что когда он был нужен, он был слишком медленным. А сейчас уже nobody cares.

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

будем надеяться, что на bzr не перейдут потом.

Не имею ничего против bzr, но точно не перейдут, там же GPL.

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

Потому что когда он был нужен, он был слишком медленным. А сейчас уже nobody cares.

Нормальная система, простая для начинающих. Особенно для не профессиональных программистов, а физиков всяких.

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

Я искренне не понимаю людей, которые их писали. Неужели им лень было прочитать несколько строк хелпа внизу выдачи rebase -i

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

Просто в git они замаскированы гит-специфичными заклинаниями

Нет, в git «заклинания» как раз отражают настоящую суть производимых операций, вместо того, чтобы пытаться изображать svn. Как только это понимаешь, все становится понятно на интуитивном уровне.

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

Фраза Мортона «your output is patches» - наверное, самое важное для понимания распределенной разработки (а может, и разработки вообще).

git format-patch, все остальное - костыли.

Патчи, которые output, это твои коммиты, в таком же виде они и ложатся в апстрим.

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

И это даже не углубляясь в более продвинутые вещи, типа MQ (где аналоги «в семействе VCS»? quilt не в счёт)

Как я уже объяснял выше, в гите все возможности mq легко достижимы с помощью git rebase -i в обычном бранче.

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

quilt, mq и stgit будут смотреть на вас с легкой грустью.

Я искренне не понимаю людей, которые их писали. Неужели им лень было прочитать несколько строк хелпа внизу выдачи rebase -i

Школота.

в git «заклинания» как раз отражают настоящую суть производимых операций, вместо того, чтобы пытаться изображать svn.

Когда поймешь, что единственное принципиальное отличие Git от SVN - это распределенность графа ревизий, заходи.

Фраза Мортона «your output is patches» - наверное, самое важное для понимания распределенной разработки (а может, и разработки вообще).

git format-patch, все остальное - костыли.

Школота.

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

единственное принципиальное отличие Git от SVN - это распределенность графа ревизий, заходи.

Школота. Когда прочитаешь про снапшоты и прочее, заходи.

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

Школота.

В отличие от тебя, я знаю историю. В частности, историю Git (и DVCS вообще).

Когда прочитаешь про снапшоты

http://gitref.org/basic/

«Git is all about composing and saving snapshots of your project and then working with and comparing those snapshots. This section will explain the commands needed to compose and commit snapshots of your project».

Напомнило старую шутку: «Каждое поколение думает, что имнно оно изобрело секс».

и прочее

Ну-ну, и какие еще революционные фишки изобретены в Git?

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

http://git-scm.com/book/en/Getting-Started-Git-Basics

The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data.

После «any other» можно не читать. Но, если прочитать, то:

Git doesn’t think of or store its data this way. Instead, Git thinks of its data more like a set of snapshots of a mini filesystem.

Становится понятно, что безграмотные фанбои такие безграмотные и, конечно, не слышали, что нижний уровень SVN даже называется SVNFS и как раз делает snapshots of a mini filesystem.

И, для протокола: по ссылке написана словесная шелуха. Имеет значение только распределенный граф ревизий (который сделали на основе SVNFS еще до Git).

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

http://www.jmadden.eu/index.php/svnfs/

Блин, да ты издеваешься. Или ты правда настолько мало знаешь о SVN?

http://en.wikipedia.org/wiki/Apache_Subversion:

«Internally, a Subversion system comprises several libraries arranged as layers. Each performs a specific task and allows developers to create their own tools at the desired level of complexity and specificity.

Fs The lowest level; it implements the versioned filesystem which stores the user data.»

сам SVN как хранил дельты между ревизиями, так и хранит.

Ты не поверишь, но в pack-файлах Git тоже хранятся дельты. Изначальное решение не хранить дельты (в раннем Git каждый измененный файл хранился полностью) вело к таким неприемлемым тормозам, что несмотря на пиар и использование «самим Линусом!!11» народ начал мигрировать на Mercurial (Xen, e2fsprogs).

Но пойнт в том, что _принципиально неважно_, как хранятся ревизии, если можно восстановить состояние дерева на момент каждого коммита, а это поддерживается в любой современной VCS.

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

Ты не поверишь, но в pack-файлах Git тоже хранятся дельты

Между произвольно выбираемыми ревизиями, а не последовательно.

Но пойнт в том, что _принципиально неважно_, как хранятся ревизии, если можно восстановить состояние дерева на момент каждого коммита, а это поддерживается в любой современной VCS.

На самом деле, это принципиально важно, так как позволяет сделать правку истории и перестановку коммитов полноценной частью воркфлоу

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

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

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