Здравствуйте, Aikin, Вы писали:
G>>>Неужели? G>>>http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/reusing_a_checkout.html A>>Ты не соскавай. Просил "минус такого подхода", я его назвал. A>А чтобы тебе было интереснее отвечать, я попрошу назвать хоть один плюс этого подхода. Существенный плюс. Который мог бы компенсировать озвученый мной минус.
Не интересно. Озвученный тобой минус в реальности отсутствует, что показано моей ссылкой. Раз его нет, то нет необходимости его и "компенсировать".
Re: Командная работа в Mercurial (или другой DVCS)
Здравствуйте, Андрей Е, Вы писали:
АЕ>Расскажите пожалуйста, как можно правильно организовать командную работу в распределенной системе контроля версий? АЕ>Допустим есть центральный репозиторий. АЕ>Есть локальные репозитории у каждого из разработчиков.
АЕ>В процессе работы разработчик создает большое количество мелких промежуточных коммитов. При этом зачастую проекты на этих коммитах не собираются или не работают.
Для этого придумали branch и HG их поддерживает в полной мере.
АЕ>Так же разработчик кучу мелких веток и по завершении работы на ними вливает их в основную ветку.
В DVCS в этом нет необходимости. Пусть вливает только завершенные, либо раз в день, либо еще как. Если делать branch на разработчика, то никаких проблем. АЕ>Еще у него висит куча тупиковых незавершенных веток.
не страшно, пусть висит.
АЕ>По умолчанию команда push проталкивает всю это гору ревизий на центральный сервер. Даже если эта гора ревизий добавляет в проект одну фичу. Проталкиваются даже тупиковые ветки.
ветки в бранчи и никаких проблем. АЕ>Если изменения выкладывают несколько разработчиков, центральный репозиторий быстро превращается в помойку.
В Visual HG есть фильтрация графа изменений по branch-ам.
АЕ>Можно попытаться ограничить разработчиков, и требовать чтобы они коммитили только когда завершают работу над фичей. Но тогда теряются все достоинства работы с распределенной системой. Зачем мне свой репозиторий, если я не могу творить с ним что хочу?
Пусть творят что хотят в своих ветках.
АЕ>Поделитесь пожалуйста опытом, как вы решаете эту проблему?
В общем, никак. Проблемы как таковой нет, если вовремя делать бранч на фичу, бранч на разработчика, или еще как, лишь бы не валить все в одну ветку.
АЕ>Возможно можно как-то вести некую основную ветку и сливать в нее только завершенные фичи, без промежуточных коммитов? И на центральном репозитории держать только эту ветку.
Можно, но смысла ограничивать ветки в центральном репозитории нет. Там итак будут ветка default и все остальное. В default будет попадать лишь то, что в нее попадает. Если разработчики будут вести разработку в других ветках, то в default будут попадать лишь результаты merge-ев. АЕ>Или есть какой то другой способ?
Способов можно навыдумывать, но смысла в них я не вижу. Создание нескольких центральных репозитониев приведет к большой каше.
АЕ>В первую очередь, интересует решение этой проблемы для Mercurial. Но если есть системы, в которых эта проблема решается просто и естественно, было бы тоже интересно узнать.
HG поддерживает бранчи, переключение между ними быстро и удобно, быстрее и удобнее чем скопировать рабочий каталог.
Re: Командная работа в Mercurial (или другой DVCS)
Здравствуйте, Андрей Е, Вы писали:
АЕ>Расскажите пожалуйста, как можно правильно организовать командную работу в распределенной системе контроля версий?
Здравствуйте, rising_edge, Вы писали:
_>В гите гору коммитов можно уменьшить: git rebase --interactive.
rebase переписывает историю. Зачем нам контроль версий, если в итоге история версий не сохраняется?
_>Пусть творит что хочет, но перед выкладыванием в центральный репозиторий пусть наведёт порядок.
Мне кажется это тоже неправильно. По моему мнению, локальную историю лучше сохранить.
Re[5]: Командная работа в Mercurial (или другой DVCS)
Здравствуйте, Андрей Е, Вы писали:
АЕ>По умолчанию команда push проталкивает всю это гору ревизий на центральный сервер. Даже если эта гора ревизий добавляет в проект одну фичу. Проталкиваются даже тупиковые ветки.
В гите push заталкивает одну ветку. Текущую или явно указанную.
В гите гору коммитов можно уменьшить: git rebase --interactive.
АЕ>Если изменения выкладывают несколько разработчиков, центральный репозиторий быстро превращается в помойку.
АЕ>Можно попытаться ограничить разработчиков, и требовать чтобы они коммитили только когда завершают работу над фичей. Но тогда теряются все достоинства работы с распределенной системой. Зачем мне свой репозиторий, если я не могу творить с ним что хочу?
Пусть творит что хочет, но перед выкладыванием в центральный репозиторий пусть наведёт порядок.
Не в курсе, есть ли в Mercirial аналог git rebase --interactive
Re[8]: Командная работа в Mercurial (или другой DVCS)
Здравствуйте, Gaperton, Вы писали:
G>Ну, во-первых Базаар не мой, а Каноникала
В любом случае ты понял о чем я G>, во-вторых, не говори мне, что мне делать
Мое дело что мне говорить, твое дело слушать/читать меня или нет. G>, а в третьих, ты забыл ответить на вопрос:
Не забыл, я его проигнорил. Не хочется отвечать в стиле "дома ты тоже не убираешь потому что фундаментальных причин убирать нет?".
A>> Вот где через жопу сделаны ветки так это в базаре. Какой извращенный ум придумал выделять новую папку под новую ветку? G>Ну ты назови для начала хоть один минус такого подхода, поговорим.
Для меня достаточно было одного: Перенастройка development environment на новую папку.
Кстати bazaar был моей первой DVCS. Но из-за этого недостатка я с ним распрощался. Потом был Гит. Тоже не пошел. Сейчас hg уже больше года -- не нарадуюсь (это к тому, что меркуриалом я доволен не потому что ничего не видел другого)
G> Умища-то для этого, я надеюсь, хватит?
Вроде как хватило. G> Все ж попроще будет, чем систему класса bazaar/hg/git написать, нет?
У меня 19.
Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[14]: Командная работа в Mercurial (или другой DVCS)
G>>>>Неужели? G>>>>http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/reusing_a_checkout.html A>>>Ты не соскавай. Просил "минус такого подхода", я его назвал. A>>А чтобы тебе было интереснее отвечать, я попрошу назвать хоть один плюс этого подхода. Существенный плюс. Который мог бы компенсировать озвученый мной минус.
G>Не интересно. Озвученный тобой минус в реальности отсутствует, что показано моей ссылкой. Раз его нет, то нет необходимости его и "компенсировать".
Раз ты настаиваешь, что твое незнание предмета (озвученный тобой "минус", сводящийся к незнанию тобой о существовании команды switch, и непониманию принципов ее работы) является почему-то минусом этого предмета, который я, как тебе кажется, должен чем-то "компенсировать", то с тобой тем более говорить бессмысленно. Иди читай документацию.
Никогда не спорю с людьми, не отличающими "я этого не понимаю" от "я с этим не согласен", ибо этот случай крайне тяжел, и, как правило, лечению не поддается.
Расскажите пожалуйста, как можно правильно организовать командную работу в распределенной системе контроля версий?
Допустим есть центральный репозиторий.
Есть локальные репозитории у каждого из разработчиков.
В процессе работы разработчик создает большое количество мелких промежуточных коммитов. При этом зачастую проекты на этих коммитах не собираются или не работают.
Так же разработчик кучу мелких веток и по завершении работы на ними вливает их в основную ветку.
Еще у него висит куча тупиковых незавершенных веток.
По умолчанию команда push проталкивает всю это гору ревизий на центральный сервер. Даже если эта гора ревизий добавляет в проект одну фичу. Проталкиваются даже тупиковые ветки.
Если изменения выкладывают несколько разработчиков, центральный репозиторий быстро превращается в помойку.
Можно попытаться ограничить разработчиков, и требовать чтобы они коммитили только когда завершают работу над фичей. Но тогда теряются все достоинства работы с распределенной системой. Зачем мне свой репозиторий, если я не могу творить с ним что хочу?
Поделитесь пожалуйста опытом, как вы решаете эту проблему?
Возможно можно как-то вести некую основную ветку и сливать в нее только завершенные фичи, без промежуточных коммитов? И на центральном репозитории держать только эту ветку.
Или есть какой то другой способ?
В первую очередь, интересует решение этой проблемы для Mercurial. Но если есть системы, в которых эта проблема решается просто и естественно, было бы тоже интересно узнать.
Здравствуйте, Андрей Е, Вы писали:
АЕ>В процессе работы разработчик создает большое количество мелких промежуточных коммитов. При этом зачастую проекты на этих коммитах не собираются или не работают.
Собираться должны. Стараемся поддерживать этот инвариант. Желательно, чтоб всё ещё и работало, но это слишком жёсткое ограничение. В идеале, закоммитить в локальный репозиторий должно быть так же легко и непринуждённо, как нажать Ctrl+S в Word'е для сохранения документа.
Центральный репозиторий настроен так, чтобы нельзя было запушить несколько голов. Т.е. тот, кто пушит, ответственен за слияние.
Именованные ветки не практикуем, но можно бы. Если надо откатиться к старой ревизии, просто не откатываемся в середину ветки, а куда-нибудь после слияния. Но это нужно очень редко. Будет нужно чаще, будем заморачиваться с именованными ветками для фичи/разработчика.
Здравствуйте, Андрей Е, Вы писали:
_>>Пусть творит что хочет, но перед выкладыванием в центральный репозиторий пусть наведёт порядок. АЕ>Мне кажется это тоже неправильно. По моему мнению, локальную историю лучше сохранить.
Причёсывание локальной истории перед сдачей в центральный репозиторий тратит время одного человека. Копание потом в непричёсанной истории тратит время всей команды.
Re[3]: Командная работа в Mercurial (или другой DVCS)
Здравствуйте, Андрей Е, Вы писали:
АЕ>Здравствуйте, rising_edge, Вы писали:
_>>В гите гору коммитов можно уменьшить: git rebase --interactive. АЕ>rebase переписывает историю.
Ты так говоришь, будто это что-то плохое.
Из Миниправа к Вам уже выехали.
АЕ>Зачем нам контроль версий, если в итоге история версий не сохраняется?
git сохраняет историю истории. Другое дело, она потом выкидывается во время garbage collection. Но если так хочется, можно оставлять всё.
_>>Пусть творит что хочет, но перед выкладыванием в центральный репозиторий пусть наведёт порядок. АЕ>Мне кажется это тоже неправильно. По моему мнению, локальную историю лучше сохранить.
Сохраняй локально, если хочется, но заставлять всех копаться в твоём мусоре — как минимум негуманно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re: Командная работа в Mercurial (или другой DVCS)
Здравствуйте, Андрей Е, Вы писали:
АЕ>Расскажите пожалуйста, как можно правильно организовать командную работу в распределенной системе контроля версий?
Объяснение про варианты командной работы с Bazaar. Эти варианты, с поправкой на разницу в командах, сработают с любой DVCS — git, mercurial, и.т.д. http://wiki.bazaar.canonical.com/Workflows
Re[2]: Командная работа в Mercurial (или другой DVCS)
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Андрей Е, Вы писали:
АЕ>>Расскажите пожалуйста, как можно правильно организовать командную работу в распределенной системе контроля версий?
G>Объяснение про варианты командной работы с Bazaar. Эти варианты, с поправкой на разницу в командах, сработают с любой DVCS — git, mercurial, и.т.д. G>http://wiki.bazaar.canonical.com/Workflows
ТС спрашивал совсем не об этом.
СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[3]: Командная работа в Mercurial (или другой DVCS)
Здравствуйте, Aikin, Вы писали:
АЕ>>>Расскажите пожалуйста, как можно правильно организовать командную работу в распределенной системе контроля версий?
G>>Объяснение про варианты командной работы с Bazaar. Эти варианты, с поправкой на разницу в командах, сработают с любой DVCS — git, mercurial, и.т.д. G>>http://wiki.bazaar.canonical.com/Workflows A>ТС спрашивал совсем не об этом.
Да, сейчас посмотрел — в самом деле. Однако — что интересно:
> В первую очередь, интересует решение этой проблемы для Mercurial. Но если есть системы, в которых эта проблема решается просто и естественно, было бы тоже интересно узнать.
В Bazaar, на доку по которому я дал ссылку, push всегда локален для ветки, и проблемы, обозначенной автором, не стоит.
Re[4]: Командная работа в Mercurial (или другой DVCS)
Здравствуйте, Gaperton, Вы писали:
>> В первую очередь, интересует решение этой проблемы для Mercurial. Но если есть системы, в которых эта проблема решается просто и естественно, было бы тоже интересно узнать. G>В Bazaar, на доку по которому я дал ссылку, push всегда локален для ветки, и проблемы, обозначенной автором, не стоит.
Мое мнение -- автор придумал себе проблему и пытается ее решить.
Если репозиторий локальный, это не значит, что надо в нем гадить.
С другой стороны терять исторюию он не хочет
. A>>В общем он сам еще не определился что именно ему нужно.
Q>По-моему, понятно. Сохранять промежуточные изменения хочет, публиковавть — нет.
Ок, логика понятна. К ней возникает вагон вопросов, но фиг с ней. Спасибо.
Здравствуйте, Aikin, Вы писали:
A>К ней возникает вагон вопросов, но фиг с ней.
Ну не скажите, я был бы не против, если б этот вагон кто-нибудь разгрузил.
Например, возможен такой сценарий (но, вероятно, я хочу неправильного). К репозиторию как-то прикручена авторизация в том или ином виде. Любой желающий (или уполномоченный) может сделать клон центрального репозитория (система по-прежнему распределённая, то есть центральный репозиторий не отличается принципиально от локальных). И ему будет видна только крупнодисперсная история. То есть все ревизии «хорошие», удовлетворяют какому-то сильному инварианту, скажем, «проект компилируется и устойчив к smoke test'ам». Если куда-то вкралась ошибка, то он может оценить первую испорченную версию лишь грубо, скажем, как 3.1.4.
Но авторизовавшись, разработчик получает более мелкую и грязную свою историю. Тут уже все ревизии удовлетворяют более мягкому инварианту, скажем, только «проект компилируется», или вовсе никак не причёсаны. Они позволяют разработчику с меньшим шагом пройтись по истории в поисках момента возникновения ошибки, скажем, в версии 3.1.4.15926.
Глаза у меня добрые, но рубашка — смирительная!
Re[6]: Командная работа в Mercurial (или другой DVCS)
Здравствуйте, Gaperton, Вы писали:
G>Или единственная веская причина в том, что в HG работа с бранчами сделана через интересное место?
Ты б уж молчал со своим Базаром. Вот где через жопу сделаны ветки так это в базаре. Какой извращенный ум придумал выделять новую папку под новую ветку?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[7]: Командная работа в Mercurial (или другой DVCS)
Здравствуйте, Aikin, Вы писали:
G>>Или единственная веская причина в том, что в HG работа с бранчами сделана через интересное место? A>Ты б уж молчал со своим Базаром.
Ну, во-первых Базаар не мой, а Каноникала, во-вторых, не говори мне, что мне делать, а в третьих, ты забыл ответить на вопрос:
A>>Если репозиторий локальный, это не значит, что надо в нем гадить. G> С чего бы это? На это есть фундаментальные причины?
Сложности с ответом? Так и скажи, не стесняйся.
A> Вот где через жопу сделаны ветки так это в базаре. Какой извращенный ум придумал выделять новую папку под новую ветку?
Ну ты назови для начала хоть один минус такого подхода, поговорим. Умища-то для этого, я надеюсь, хватит? Все ж попроще будет, чем систему класса bazaar/hg/git написать, нет?
Re[9]: Командная работа в Mercurial (или другой DVCS)
Здравствуйте, Aikin, Вы писали:
G>>Ну, во-первых Базаар не мой, а Каноникала A>В любом случае ты понял о чем я
Не, не понял.
G>>, во-вторых, не говори мне, что мне делать A>Мое дело что мне говорить, твое дело слушать/читать меня или нет.
Твои дела меня совершенно не интересуют, и в мои дела тоже лезь не надо.
Будешь продолжать, как пыонер, переводить разговор на личности — я объясню тебе, куда идти, и разговор закончится. И все.
G>>, а в третьих, ты забыл ответить на вопрос: A>Не забыл, я его проигнорил. Не хочется отвечать в стиле "дома ты тоже не убираешь потому что фундаментальных причин убирать нет?".
То есть, не хочется говорить откровенной глупости, а по существу вопроса сказать нечего?
Экспериментальные бранчи для быстрого и грязного прототипирования, ты, очевидно, не делаешь именно потому, что всегда дома убираешься, да?
A>>> Вот где через жопу сделаны ветки так это в базаре. Какой извращенный ум придумал выделять новую папку под новую ветку? G>>Ну ты назови для начала хоть один минус такого подхода, поговорим. A>Для меня достаточно было одного: Перенастройка development environment на новую папку.
Факт, что в bzr (в отличии от) положение branch-а не обязано соответствовать положению рабочей копии (и бранч может вообще не иметь рабочей копии), очевидно, от тебя ускользнул?
А это, меж тем, основы модели работы с бранчами в bzr.
A>Кстати bazaar был моей первой DVCS. Но из-за этого недостатка я с ним распрощался.
Конечно. Не мануалы же читать, в конце концов. Даже если мануал хороший, и текста в нужном месте всего полстраницы.
A>Потом был Гит. Тоже не пошел. Сейчас hg уже больше года -- не нарадуюсь (это к тому, что меркуриалом я доволен не потому что ничего не видел другого)
А я, напротив, начинал с HG. Забавно, как у нас все наоборот-то.
G>> Умища-то для этого, я надеюсь, хватит? A>Вроде как хватило.
О да.
G>> Все ж попроще будет, чем систему класса bazaar/hg/git написать, нет? A>У меня 19.
Неужели? .
Re[10]: Командная работа в Mercurial (или другой DVCS)
Здравствуйте, Gaperton, Вы писали:
G>Будешь продолжать, как пыонер, переводить разговор на личности — я объясню тебе, куда идти, и разговор закончится. И все.
Мы можем закончить прямо сейчас. Пошлеш ты меня или нет мне фиолетово.
G>Экспериментальные бранчи для быстрого и грязного прототипирования, ты, очевидно, не делаешь именно потому, что всегда дома убираешься, да?
Делаю.
Если код важный -- пушу его, нет -- удаляю из своего репозитория. Есть еще вариант когда этот код комититься в личный репозиторий, а не рабочий. если прототип -- отдельное приложение, то его можно поместить в дефалтную ветку, но отдельную папку.
Вариантов вагон.
И, кстати, в меркуриале есть возможность пушить конкретный бранч.
G>что всегда дома убираешься, да?
Раздул так раздул.
G>>>Ну ты назови для начала хоть один минус такого подхода, поговорим. A>>Для меня достаточно было одного: Перенастройка development environment на новую папку. G>Неужели? G>http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/reusing_a_checkout.html
Ты не соскавай. Просил "минус такого подхода", я его назвал.
G>http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/reusing_a_checkout.html G>Факт, что в bzr (в отличии от) положение branch-а не обязано соответствовать положению рабочей копии (и бранч может вообще не иметь рабочей копии), очевидно, от тебя ускользнул? G>А это, меж тем, основы модели работы с бранчами в bzr.
Очень удивлен. Даже по версиям прошелся. Оказывается эта фича была в моем махровом году (2009). Всегда пользовался гуем. Может в нем этой фичи не было на тот момент.
Тем более удивлен, что челы, которые работали с базаром давно об этой фиче не знают: http://solovyov.net/blog/2011/01/24/bzr-hate-and-hate/
G>А я, напротив, начинал с HG. Забавно, как у нас все наоборот-то.
Забавно. Я начинал с твоей подачи. Так что к тому времени ты отказался от hg и стал работать с bazaar. hg я попробовал много позже (+ ~пол года). Может к этому времени hg "повзрослел".
G>>> Все ж попроще будет, чем систему класса bazaar/hg/git написать, нет? A>>У меня 19. G>Неужели? .
Фотку прислать? Но боюсь ты все равно не повериш и скажешь что фотошоп
СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[11]: Командная работа в Mercurial (или другой DVCS)
Здравствуйте, Aikin, Вы писали:
G>>А это, меж тем, основы модели работы с бранчами в bzr. A>Очень удивлен. Даже по версиям прошелся. Оказывается эта фича была в моем махровом году (2009). Всегда пользовался гуем. Может в нем этой фичи не было на тот момент.
Ну конечно же была. См. например bzr qswitch. Дело не в гуе, а в том, что ты не понимаешь модели бранчей базара, которая (внезапно!) объясняется в документации, а не гуе. Возможность переключать бранчи в одном месте — это одно из простейших свойств модели.
A>Тем более удивлен, что челы, которые работали с базаром давно об этой фиче не знают: http://solovyov.net/blog/2011/01/24/bzr-hate-and-hate/
Да в мире вообще много удивительных вещей.
Вот, например, бывает, что на заборе "х-й" написано, в то время как за ним, забором, (внезапно!) дрова лежат. Представляешь, как бы ты удивился, заглянув за забор, и обнаружив там (кто бы мог подумать) дрова?
А тем более удивительно, что челы, которые работали с забором, об этой фиче не знают. Давно ведь с забором работают-то, с младших классов!
A>Мы можем закончить прямо сейчас. Пошлеш ты меня или нет мне фиолетово.
Годится. Ступай.
Re[12]: Командная работа в Mercurial (или другой DVCS)
Ну вот, увел беседу в сторону и ответил совсем не на то.
Давай я верну контекст назад: A>>>>> Вот где через жопу сделаны ветки так это в базаре. Какой извращенный ум придумал выделять новую папку под новую ветку? G>>>>Ну ты назови для начала хоть один минус такого подхода, поговорим. : A>>>Для меня достаточно было одного: Перенастройка development environment на новую папку. G>>Неужели? G>>http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/reusing_a_checkout.html A>Ты не соскавай. Просил "минус такого подхода", я его назвал.
А чтобы тебе было интереснее отвечать, я попрошу назвать хоть один плюс этого подхода. Существенный плюс. Который мог бы компенсировать озвученый мной минус.
Вопрос не в том, что я "сам дурак что не читаю доки", а в том, что такой подход к ветвлению сделан разработчиками Базара основным. А если он кого-то не устраивает: "вот вам дока, там написано как сделать по-другому, но учтите, это будет не легко".
СУВ, Aikin
Сообщение назад тебя очень интересовал мой ответ на вопрос: "Я:Если репозиторий локальный, это не значит, что надо в нем гадить. ТЫ:С чего бы это? На это есть фундаментальные причины?". Больше не интересует?
G>>>А это, меж тем, основы модели работы с бранчами в bzr. A>>Очень удивлен. Даже по версиям прошелся. Оказывается эта фича была в моем махровом году (2009). Всегда пользовался гуем. Может в нем этой фичи не было на тот момент. G>Ну конечно же была. См. например bzr qswitch. Дело не в гуе, а в том, что ты не понимаешь модели бранчей базара, которая (внезапно!) объясняется в документации, а не гуе. Возможность переключать бранчи в одном месте — это одно из простейших свойств модели.
Давай не будем переходит на личности. А еще лучше и закроем эту линию. Друг друга мы долго еще можем обсуждать
A>>Мы можем закончить прямо сейчас. Пошлеш ты меня или нет мне фиолетово. G>Годится. Ступай.
Рано
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[15]: Командная работа в Mercurial (или другой DVCS)
G>Никогда не спорю с людьми, не отличающими "я этого не понимаю" от "я с этим не согласен", ибо этот случай крайне тяжел, и, как правило, лечению не поддается.
Разве что дубиной по голове. Но в сети таких тысячи, и мне за это не платят.
Re[15]: Командная работа в Mercurial (или другой DVCS)
Специально для того, чтобы ты не отвечал в том духе в котором ответил, я озвучил причину по которой меня все еще интересует этот вопрос:
Вопрос не в том, что я "сам дурак что не читаю доки", а в том, что такой подход к ветвлению сделан разработчиками Базара основным. А если он кого-то не устраивает: "вот вам дока, там написано как сделать по-другому, но учтите, это будет не легко"
Но ты ведь не читаешь то что тебе пишут. Зачем?
Aikin
P.S. Кстати я очень рад что мое "незнание предмета" способствовало отказу от этого "предмета" в пользу другого "предмета" который не требует от меня каких-то специфичных знаний.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[16]: Командная работа в Mercurial (или другой DVCS)
Здравствуйте, Aikin, Вы писали:
A>P.S. Кстати я очень рад что мое "незнание предмета" способствовало отказу от этого "предмета" в пользу другого "предмета" который не требует от меня каких-то специфичных знаний.
Так радуйся на здоровье, я разве против? Еще можно своим незнанием предмета немного погордится, и обязательно влезть с ним в какой-нибудь холивар. Это теперь модно.
Re[17]: Командная работа в Mercurial (или другой DVCS)
Здравствуйте, Gaperton, Вы писали:
A>>P.S. Кстати я очень рад что мое "незнание предмета" способствовало отказу от этого "предмета" в пользу другого "предмета" который не требует от меня каких-то специфичных знаний.
G>Так радуйся на здоровье, я разве против? Еще можно своим незнанием предмета немного погордится, и обязательно влезть с ним в какой-нибудь холивар. Это теперь модно.
Модно сейчас не читая собеседника отвечать на всякую второстепенную фигню.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[18]: Командная работа в Mercurial (или другой DVCS)
Здравствуйте, Aikin, Вы писали:
G>>Так радуйся на здоровье, я разве против? Еще можно своим незнанием предмета немного погордится, и обязательно влезть с ним в какой-нибудь холивар. Это теперь модно. A>Модно сейчас не читая собеседника отвечать на всякую второстепенную фигню.
Ты в своих комментах превысил разумные объемы всякой второстепенной фигни, так что нефиг жаловаться. Что хотел — то и получил.
