Hg/Mercurial 3.4

Для gitlib'а процесс описан здесь

Не нашел там диффов между патчами и объединения разных версий одного патча.

Вообще, конечно, из этих трёх gerrit, похоже, самый продвинутый

AFAIK, у него внутри независимая реализация Git на Java или что-то близкое к тому.

какие ещё применения, помимо code-review и тому подобного, есть у отслеживания изменений в изменениях?

Многопользовательский mq на стероидах. Просто для коллективной разработки серии патчей, без привлечения серверов на Java EE.

А не знаете, когда они планируют слезать с python2?

«Mercurial 3.4 объявлен последним выпуском, в котором поддерживаются ветки Python 2.4 и 2.5.», — пишут в новости на Opennet.ru.

Mercurial 3.5 будет поддерживать Python 2.7 или сразу 3.x?

Не так-то просто перепозти на 3.x с 2.7. А то, что оно, оказывается, 2.4 до сих пор работало - для меня новость. :)

Не нашел там диффов между патчами и объединения разных версий одного патча.

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

AFAIK, у него внутри независимая реализация Git на Java или что-то близкое к тому.

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

Просто для коллективной разработки серии патчей, без привлечения серверов на Java EE.

Ну, в целом, это напоминает принципиальное нежелание ездить на механизированном транспорте. Сервер поднимается несложно. Хотя, конечно, да, от «принципиально децентрализованной» разработки подход с gerrit'ом уводит.

Ну, в целом

В целом, у меня подозрение, что ты говоришь о чем-то другом.

это напоминает принципиальное нежелание ездить на механизированном транспорте

Да ладно, не сдерживайся. Назови меня луддитом, например.

В целом, у меня подозрение, что ты говоришь о чем-то другом.

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

Назови меня луддитом, например.

Бобёр, выдыхай. Не, конечно, если у тебя есть желание, мы можем продолжить сеанс срывания покровов и прочих каминь-аутов, но, если честно, исходно я ничего такого не имел ввиду.

В самом деле, я не вижу никакой проблемы в поднятии какого угодно сервиса в рамках выполнения подобной регулярно выполняемой задачи, поскольку задача является практически краеугольным камнем организации процесса коллективной работы в создании ПО.

В целом, у меня подозрение, что ты говоришь о чем-то другом.

(Озадаченно) всё о том же, о сервере организации коллективной работы над цепочкой (или сетью) изменений

Вот-вот. Я-то о сервере вообще не говорил.

Меня интересует простой сценарий:

• прогер делает 2 патча, A и B, пушит (пусть в Gerrit)
• продолжает работу, в процессе которой патчи A и B становятся A1 и B1
• другой прогер берет с сервера A и B, модифицирует их, получая A2 и B2, и пушит

Теперь первый прогер должен как-то объединить A1 и A2, B1 и B2. Если он пуллит A2 и B2 себе в репозиторий, то как няшне Gerrit поможет ему в собственно объединении? Как вообще Gerrit поможет первому прогеру разрулить ситуацию?

Не, конечно, если у тебя есть желание, мы можем продолжить сеанс срывания покровов и прочих каминь-аутов

Ну, ты это начал, если есть желание - продолжай, не сдерживайся.

Я так и не смог его заставить коммитить на git-сервер изменения, чтобы они через какое-то время не начинали вызывать конфликты на git-стороны (при чём кроме hg-git с той стороной никто не работал).

ого. накопать информации на багрепорт пробовали?

Как вообще Gerrit поможет первому прогеру разрулить ситуацию?

никак. evolution надо попробовать чтобы понять //заядлый пользователь геррита, фабрикатора и меркуриала.

Как вообще Gerrit поможет первому прогеру разрулить ситуацию?

никак

Вот и мне кажется. Разве что Gerrit умеет мержить патчи прямо на сервере.

• прогер делает 2 патча, A и B, пушит (пусть в Gerrit)
• продолжает работу, в процессе которой патчи A и B становятся A1 и B1
• другой прогер берет с сервера A и B, модифицирует их, получая A2 и B2, и пушит

Ченджсеты в Gerrit'е отделёны от «настоящего» git-репозитория до тех пор, пока пройдя code-review они не будут замержены в основной код. Т.е. то, что запушено «пусть в Gerrit», есть только у Gerrit'а, его можно получить по уникальному идентификатору, но его нет в git'е до тех пор, пока не будет сделан merge для ченджсета.

Значит, когда прогер на третьем шаге берёт код то у него есть два варианта: либо берёт то, что замержено в master и тогда у него просто нет указанного ченджсета, либо берёт данный конкретный ченджсет и тогда он точно знает что делает. Впрочем, есть третий вариант, когда A и B замержены в основную ветку, но тогда A1 и B1 будут являться отдельным ченджсетом поверх A и B, так же как и A2 и B2.

Насколько я понимаю, ты сказал «Gerrit здесь ничем не поможет», но другими словами.

Не совсем… Gerrit — это совсем другой workflow.

И кстати, нифига code-review, даже Gerrit'овский (т.е. ДО помещения кода в основную ветку), не спасает от косяков. И сам косячил, и косячный код ревьюил… :-(

Насколько я понимаю, ты сказал «Gerrit здесь ничем не поможет», но другими словами.

Не совсем…

Окей, тогда вопрос тот же: как именно Gerrit поможет объединить A1 и A2, B1 и B2.

Gerrit — это совсем другой workflow.

Это другой usecase.

ого. накопать информации на багрепорт пробовали?

Для этого надо слишком хорошо разобраться со всей инопланетной логикой git-потрохов :) Пока некогда и ломает, для git хватает тупого использования.

Как вообще Gerrit поможет первому прогеру разрулить ситуацию?

Ну, как обычно. Простые, бесконфликтные ситуации можно разрулить прямо из веб-интерфейса (например, заребэйзить коммит, если это можно сделать без вмешательства человека). Для каких-то сложных случаев, требующих осмысленного редактирования файлов, необходимо вытащить нужные версии нужных ченджсетов (не путать с ревизиями уже заапрувленных коммитов) из git'а себе на машину в виде временных бранчиков, например так:

git fetch origin refs/changes/27/81427/1:unsigned/81427

Здесь 81427 - номер ченджсета в истории геррита, 1 - первая версия этого ченджсета, а всё, что после двоеточия - это имя локального бранча на этот случай в удобной персонально мне политике именования. Однако, замечу, это понимание необязательно, т.к. требуемая команда для выбранной версии текущего ченджсета фигурирует прямо на соответствующей страничке в геррите, копипастится по клику.

А дальше ты работаешь с этим ответвлением как с обычным бранчем, в том числе, меняя, добавляя или убирая коммиты. Результат по готовности пушится обратно в геррит

git push origin HEAD:refs/for/<feature_branch>

В этом случае, в ситуации, когда есть несколько вариантов развития (A-B, A1-B1, A2-B2...), у тебя есть три (временных) бранча с парой коммитов в каждом, из которых ты волен тягать друг в друга изменения любым нравящимся тебе способом, внутренним для git'а (например,

git cherry-pick

git rebase -i

Ну, ты это начал, если есть желание - продолжай, не сдерживайся.

Ты один на это ринге.

Если ты воспринял как персональное оскорбление сравнение неиспользования серверов на JEE с отказом от механизированных средств передвижения, то я готов извиниться за это сравнение. Меня эта тема совершенно не трогает, и как-то задеть тебя я не пытался, а уже сколько сообщений подряд вынужден тратить на обсуждение этой фразы время из-за твоей нервной реакции.

но его нет в git'е до тех пор, пока не будет сделан merge для ченджсета.

Ну, нет, это не совсем правильное объяснение. Незасабмитанные коммиты - это обычные коммиты в терминах git'а, просто они не являются [пока] частью «публично доступных бранчей», только через «служебные бранчи геррита». Разница между публичным и служебным в данном случае - ровно в том, что первые видны по `git branch -r` и получаются обычным git fetch'ем по умолчанию, а вторые нужно вытягивать по определённому имени.

Продолжение:

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

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

Мне не нужен rebase. Мне нужен merge с подвыподвертом.

Для каких-то сложных случаев, требующих осмысленного редактирования файлов, необходимо вытащить нужные версии нужных ченджсетов (не путать с ревизиями уже заапрувленных коммитов) из git'а себе на машину

...и проделать вручную то, что автоматизируется evolve.py

...и проделать вручную то, что автоматизируется evolve.py

Так,погоди,я сказал 'всех'. То есть, rerere с компанией и даже filter-branch у тебя тоже есть. Но, не спорю, скриптинг на питоне может оказаться приятнее. Впрочем, кто-то его на дух не переносит, почитай вон тред о jython. Да и мой опыт совместной работы над комитами до сих пор оказывался таким, что всерьез там немного что можно было бы автоматизировать.

В целом, конечно, процедура 'сделал коммит'-'залил на ревью'-'получил оплеух и обновленную версию'-'скачал обновленную версию'-'пошел их мёржить' в случае гита оказывается на один шаг длиннее, 'скачал обновленную версию'

rerere с компанией и даже filter-branch у тебя тоже есть.

Да ты издеваешься.

скриптинг на питоне

Скриптинг - это когда начинаются каскады git rebase, git rerere и git filter-branch.

Видишь, сейчас мы обсуждаем сферического мержа в вакууме, а в таких условиях что evolve.py, что filter-branch. что вулканы на Плутоне. Я допускаю, что из этих трех тебе в любых условиях милее evolve.py, но, мне представляется, это, во многом, импринтинг