Расскажите пожалуйста, как можно правильно организовать командную работу в распределенной системе контроля версий?
Допустим есть центральный репозиторий.
Есть локальные репозитории у каждого из разработчиков.
В процессе работы разработчик создает большое количество мелких промежуточных коммитов. При этом зачастую проекты на этих коммитах не собираются или не работают.
Так же разработчик кучу мелких веток и по завершении работы на ними вливает их в основную ветку.
Еще у него висит куча тупиковых незавершенных веток.
По умолчанию команда push проталкивает всю это гору ревизий на центральный сервер. Даже если эта гора ревизий добавляет в проект одну фичу. Проталкиваются даже тупиковые ветки.
Если изменения выкладывают несколько разработчиков, центральный репозиторий быстро превращается в помойку.
Можно попытаться ограничить разработчиков, и требовать чтобы они коммитили только когда завершают работу над фичей. Но тогда теряются все достоинства работы с распределенной системой. Зачем мне свой репозиторий, если я не могу творить с ним что хочу?
Поделитесь пожалуйста опытом, как вы решаете эту проблему?
Возможно можно как-то вести некую основную ветку и сливать в нее только завершенные фичи, без промежуточных коммитов? И на центральном репозитории держать только эту ветку.
Или есть какой то другой способ?
В первую очередь, интересует решение этой проблемы для Mercurial. Но если есть системы, в которых эта проблема решается просто и естественно, было бы тоже интересно узнать.
Re: Командная работа в Mercurial (или другой DVCS)
Здравствуйте, Андрей Е, Вы писали:
АЕ>По умолчанию команда push проталкивает всю это гору ревизий на центральный сервер. Даже если эта гора ревизий добавляет в проект одну фичу. Проталкиваются даже тупиковые ветки.
В гите push заталкивает одну ветку. Текущую или явно указанную.
В гите гору коммитов можно уменьшить: git rebase --interactive.
АЕ>Если изменения выкладывают несколько разработчиков, центральный репозиторий быстро превращается в помойку.
АЕ>Можно попытаться ограничить разработчиков, и требовать чтобы они коммитили только когда завершают работу над фичей. Но тогда теряются все достоинства работы с распределенной системой. Зачем мне свой репозиторий, если я не могу творить с ним что хочу?
Пусть творит что хочет, но перед выкладыванием в центральный репозиторий пусть наведёт порядок.
Не в курсе, есть ли в Mercirial аналог git rebase --interactive
Re: Командная работа в Mercurial (или другой DVCS)
Здравствуйте, Андрей Е, Вы писали:
АЕ>Расскажите пожалуйста, как можно правильно организовать командную работу в распределенной системе контроля версий?
Здравствуйте, Андрей Е, Вы писали:
АЕ>Расскажите пожалуйста, как можно правильно организовать командную работу в распределенной системе контроля версий? АЕ>Допустим есть центральный репозиторий. АЕ>Есть локальные репозитории у каждого из разработчиков.
АЕ>В процессе работы разработчик создает большое количество мелких промежуточных коммитов. При этом зачастую проекты на этих коммитах не собираются или не работают.
Для этого придумали branch и HG их поддерживает в полной мере.
АЕ>Так же разработчик кучу мелких веток и по завершении работы на ними вливает их в основную ветку.
В DVCS в этом нет необходимости. Пусть вливает только завершенные, либо раз в день, либо еще как. Если делать branch на разработчика, то никаких проблем. АЕ>Еще у него висит куча тупиковых незавершенных веток.
не страшно, пусть висит.
АЕ>По умолчанию команда push проталкивает всю это гору ревизий на центральный сервер. Даже если эта гора ревизий добавляет в проект одну фичу. Проталкиваются даже тупиковые ветки.
ветки в бранчи и никаких проблем. АЕ>Если изменения выкладывают несколько разработчиков, центральный репозиторий быстро превращается в помойку.
В Visual HG есть фильтрация графа изменений по branch-ам.
АЕ>Можно попытаться ограничить разработчиков, и требовать чтобы они коммитили только когда завершают работу над фичей. Но тогда теряются все достоинства работы с распределенной системой. Зачем мне свой репозиторий, если я не могу творить с ним что хочу?
Пусть творят что хотят в своих ветках.
АЕ>Поделитесь пожалуйста опытом, как вы решаете эту проблему?
В общем, никак. Проблемы как таковой нет, если вовремя делать бранч на фичу, бранч на разработчика, или еще как, лишь бы не валить все в одну ветку.
АЕ>Возможно можно как-то вести некую основную ветку и сливать в нее только завершенные фичи, без промежуточных коммитов? И на центральном репозитории держать только эту ветку.
Можно, но смысла ограничивать ветки в центральном репозитории нет. Там итак будут ветка default и все остальное. В default будет попадать лишь то, что в нее попадает. Если разработчики будут вести разработку в других ветках, то в default будут попадать лишь результаты merge-ев. АЕ>Или есть какой то другой способ?
Способов можно навыдумывать, но смысла в них я не вижу. Создание нескольких центральных репозитониев приведет к большой каше.
АЕ>В первую очередь, интересует решение этой проблемы для Mercurial. Но если есть системы, в которых эта проблема решается просто и естественно, было бы тоже интересно узнать.
HG поддерживает бранчи, переключение между ними быстро и удобно, быстрее и удобнее чем скопировать рабочий каталог.
Здравствуйте, Андрей Е, Вы писали:
АЕ>В процессе работы разработчик создает большое количество мелких промежуточных коммитов. При этом зачастую проекты на этих коммитах не собираются или не работают.
Собираться должны. Стараемся поддерживать этот инвариант. Желательно, чтоб всё ещё и работало, но это слишком жёсткое ограничение. В идеале, закоммитить в локальный репозиторий должно быть так же легко и непринуждённо, как нажать Ctrl+S в Word'е для сохранения документа.
Центральный репозиторий настроен так, чтобы нельзя было запушить несколько голов. Т.е. тот, кто пушит, ответственен за слияние.
Именованные ветки не практикуем, но можно бы. Если надо откатиться к старой ревизии, просто не откатываемся в середину ветки, а куда-нибудь после слияния. Но это нужно очень редко. Будет нужно чаще, будем заморачиваться с именованными ветками для фичи/разработчика.
Здравствуйте, rising_edge, Вы писали:
_>В гите гору коммитов можно уменьшить: git rebase --interactive.
rebase переписывает историю. Зачем нам контроль версий, если в итоге история версий не сохраняется?
_>Пусть творит что хочет, но перед выкладыванием в центральный репозиторий пусть наведёт порядок.
Мне кажется это тоже неправильно. По моему мнению, локальную историю лучше сохранить.
Re[3]: Командная работа в Mercurial (или другой DVCS)
Здравствуйте, Андрей Е, Вы писали:
_>>Пусть творит что хочет, но перед выкладыванием в центральный репозиторий пусть наведёт порядок. АЕ>Мне кажется это тоже неправильно. По моему мнению, локальную историю лучше сохранить.
Причёсывание локальной истории перед сдачей в центральный репозиторий тратит время одного человека. Копание потом в непричёсанной истории тратит время всей команды.
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[5]: Командная работа в 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[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[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.
