Свежие комментарии

linux-sun-jre-1.6.0.24 You must manually fetch the JRE self-extracting file for the Linux platform (jre-6u24-linux-i586.bin) from http://www.oracle.com/technetwork/java/javase/downloads/index.html, place it in /usr/ports/distfiles and then run make again.
это лицензионные заморочки, ты типа там с лицензией согласится должен, что б тебе дали скачать.

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

Нуууу, на FreeBSD есть полностью живой Valgrind и есть DTrace, которого не Линухе нет, а это ОЧЕНЬ мощная штука. VTune нет, да.
Виртуализация -- VirtualBox вполне поддерживается. kvm нет, факт.

По опыту работы в *ix, всё равно в больших конторах или солярка (ну и ещё немного хпукса, аикса, т.п.)., или свой переработанный дистрибутив линуха. А этот свой преработанный — всё равно, что там в начале было. Эти стенания на предмет пакедж манагеров, т.п. — кого это волнует, всё равно при разворачивании «сотни серверов» надо своё.

За Родинуфрибзду обидно, конечно, но выделенные пункты — да, никуда не пройти мимо.

И пара ссылок, рядом с этой темой: http://www.c0t0d0s0.org/archives/7386-Implications.html и (не нашёл ссылку) в последней vSphere можно делать виртуалку в виртуалке.

То что Рамблер с Я переезжают на Линукс - это не такой убедительный показатель что Фря плоха - те же полугодовые бенчмарки от того же порнослоника в домене показали что разница несущественна. Вероятно Рамблер имеет в своем штате низкоквалифицированных Unix (Linux+other) и имеет теперь Linux-only одминов - каждый использует то, что лучше знает, это факт. К тому же это все бизнес - а из-за бизнеса и людей с легкостью убивают. CUDA, кстати сказать в FreeBSD-CURRENT поддерживается (отдельным патчем). Я и сам, будь только 1 дистрибутив Linux, переехал бы и серверами и рабочей станцией на Linux. Но сейчас Linux раскалывается также как когда-то пошли порознь пути Linux-BSD - у всех разные порт-менеджеры, у многих сейчас разные X-серверы (Ubuntu привет), у многих разные системы запуска (systemd, openrc..) и что самое страшное - начали появляться дистрибутивы которым не нравяться глибцы, есть дистры с dietlibc или uClibc или Newlib. Теперь холивары между дистрибутивами Линукс а также в скором времени будут новости типа "Рамблер переехал с Debian на RedHAT". "Яндекс переезжает с CentOS на TurboLinux". Хорошо еще ядро пока у всех одно - но оно стало невероятно огромным - корпорации в своих интересах тащат туда все что не поподя, не ровен час когда эта громозека сама себя начнет переваривать.

Спасибо.
Приятно наконец то почуствовать себя не полным идиотом. :-)

Так как диффы - всегда на уровне строк, то конфликт обязательно будет.

Так как пушатся (и вообще коммитятся) не отдельные файлы, а changeset-ы (не вдавался, как это в git называется), значит там возникает блокировка (на проект?) и второй не успеет.

Значит этот самый второй при пуше - обломается (кто пришел вторым) и ему придется порезолвить конфликт.

Я так щетаю.

Вот уже и не знаю куда отвечать.
СПАСИБО!!!
Внимательно следил за вашей с J0hn дискуссией и боялся прервать. Наконец то стало проясняться про rebase и прочие нюансы и usecsae-ы.
Тупой окончательный вопрос про rebase (для себя):
Есть CMakeLists.txt и в нем допустим строка:

clahe equalizer highpass hotpixels lowlight

мы вдвоем с живчиком сделали pull, чего то там натворили, поправили CMakeLists.txt
живчик:

clahe equalizer highpass hotpixels lowlight nlmeans

я:

clahe equalizer highpass hotpixels lowlight density

Живчик успел push раньше.
я делаю pull и rebase
1) у меня случится конфликт? или втихомолку внесутся мои изменения, потеряв изменения живчика?
2) а если мы одновременно пушить начали (что конечно маловероятно). Кто последний, того и тапочки? По идее конфликт должен случиться и я думаю будет.

Можно коротко. Я уже почти достиг просветления на данном этапе.

* 1 То что merge-commit's это вообще плохо? *
Да.

Ну а как без них нормально организовать что-то чуть более сложнее одной стволовой ветки, например http://habrahabr.ru/blogs/Git/106912/ ?

или если какой то шустрик до нас запушил:

я такой rebase делаю, но merge'у с --no-ff, специально, чтобы не было fastforward. по той ссылке, с которой вы взяли картинку, чувак с ником "Apreche" делать merge-коммиты. Например показывает, что merge легче откатить, так как это один коммит, а не все мелкие коммиты.
Если делать fast-forward, то чем это всё отличается (глобально) от например svn?

А картинка должна была проиллюстрировать то чем эти мерж коммиты плохи.
выражение "merge-коммиты плохи", у меня ассоциируется с "ветвления плохи".
merge'ить ветки естественно , а полностью вливать одну ветку в другую - нет.
вот почитайте, что авторитет пишет http://kerneltrap.org/Linux/Git_Management .
например про rebase: "and basically use git as an efficient
patch-queue manager that remembers *your* patches"

Покажите свою, давайте лучше ее обсудим.
Я гит использую как клиент к удалённому svn'у - там всё линейно.
Локально же у меня feature-бранчи, которые вливаются в master, через merge --no-ff, всё чисто и аккуратно.
Мои картинки скучны - слишком прямолинейны, а обсуждать чужие похоже не очень интересно.
Неинтересно обсуждать чужие, тогда когда не ясно как эти картинки получились, и что вообще там творилось - если дадите ссылку на какой-нибудь реальный репозиторий, то я с радостью обсужу его картинки .

Что вы хотели показать этой картинкой:

1 То что merge-commit's это вообще плохо?

2.Или то что merge'ить (через merge-commit) feature-ветки в master это плохо?

Для иллюстрации 2. картинка не подходит, так как там ветки вливаются не только в master, но и между собой - что именно там происходило, вы так и не объяснили

почему образуются - это понятно,
понятно что если делать rebase, и merge с -ff (то есть просто merge) то будет fastforward.
Я конкретно спрашивал про ту картинку - там ветки merge'атся, не только в одну, но и в друг друга - что это за workflow?

Ну граф истории будет напоминать вот такой
http://www.viget.com/uploads/image/merge_commits.jpg
если работаешь один или вдвоем. Если людей поболе то конечно и проблем с этим будет поболе :)

Ещё, раз, что именно это за граф? Какоей именно там workflow? это не похоже на то, когда все merge'ат feature барнчи в главную

* А вот чтобы было в той ситуции, если бы делали rebase? Точнее что по вашему было бы в варианте с rebase? *

Если я правильно понял вопрос, то с rebase история получается линейная, и как следствие revert работает правильно потому как можно откатить любой патч, а потом откатить откат и все такое.

Это, как справедливо написано в мануале, bad idea в тому случае если ребэйз делается с коммитами которые уже лежат на сервере. Для локальных коммитов таких проблем нет. Уже два года ребейзим всем маемо, и никаких проблем.
читаем заново моё высказывание "я вот этой ситуации не понял. но если это про rebase в общем репозитории, то это как бы bad idea."
я не говорил, что rebase в локальном repo это bad idea.

А и еще, если откатываешь мерж, то в некоторых случаях можно поиметь кучу проблем, с обычными коммитами такого не будет.
Впрочем напрячься нужно будет всегда
Ну в описанной ситуации с Линусом, там всё ясно. Если revert - это всего лишь reverse commit, то так и должно быть.
А вот чтобы было в той ситуции, если бы делали rebase? Точнее что по вашему было бы в варианте с rebase?

все, объяснили тупому )) не в Castom Maps а в папку BirdsEye надо закидвать карту.