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

см. выше

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

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

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

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

Troll harder, babe.

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

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

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

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

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

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

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

Troll harder, babe.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да, Ъ git-way.

А почему бы не включить 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

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

Oh, no :(

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

Можно git воспользоваться. Репы - тут:

https://gitorious.org/freebsd

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

Еще на гитхабе есть: https://github.com/freebsd

Трындец, просто трындец.

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

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

Да, Ъ git-way.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Школота.

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

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

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

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

Школота.

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

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

Школота.

В отличие от тебя, я знаю историю. В частности, историю 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?

Не то читаешь.

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

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).

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

Насколько я понимаю, эта штука имеет достаточно косвенное отношение к внутреннему устройству SVN, а сам SVN как хранил дельты между ревизиями, так и хранит.

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.

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

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

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

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

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