Какой системой управления версиями вы пользуетесь?

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

Ты лучше расскажи, как вы нынче обходитесь без вменяемой системы коде-ревью

Нас Rhodecode устраивает.

остальными внутриконторскими системами поддержки разработки

?

Нас Rhodecode устраивает.

Я не заметил в описании, как у них патчсет лайфтайм устроен. Можно посмотреть, как менялся ченджсет по мере его обсуждения и выкатывания новых версий?

остальными внутриконторскими системами поддержки разработки

?

Ну все эти многочисленные дженкинсы, редмайны и прочие. У нас, например, при выставлении ченджсета на ревью туда первым делом набегают роботы, которые это всё компилируют, контролируют всякие вещи типа code convention'ов, запускают какие-то тесты, а потом выставляют +1/-1 по результатам своей работы. Ну и тому подобное.

Можно посмотреть, как менялся патч по мере его обсуждения?

Поскольку я не понял, о чем ты - наверное, нет (по крайней мере в 1.6, которая у нас).

Ну все эти многочисленные дженкинсы, редмайны и прочие

Redmine - это такой Trac? Тогда я не понял, в чем заключается интеграция. В документации есть об интеграции с багтрекерами, но мы этим не пользуемся.

У нас, например, при выставлении ченджсета на ревью туда первым делом набегают роботы, которые это всё компилируют, контролируют всякие вещи типа code convention'ов, запускают какие-то тесты

Это buildbot по триггеру? AFAIK, здесь понадобится поработать руками - добавлять триггеры в создаваемые форки или как-то сконфигурировать опрос в buildbot-е. Но, опять же, нам это пока не нужно. По-моему, у вас большая группа разработчиков с развесистой инфраструктурой - я плохо представляю потребности таких групп.

Поскольку я не понял, о чем ты - наверное, нет (по крайней мере в 1.6, которая у нас).

Хм. Смотри, например, https://android-review.googlesource.com/#/c/31100/ и то, как там можно посмотреть, что делалось в патчсетах с 1-го по 4 (на текущий момент). Ты можешь посмотреть, как выглядел соответствующий патч (по сравнению с «базовой» версией), а можешь посмотреть на то, что поменялось в ченджсете между, например, 2-м и 4-м патчсетами.

Redmine - это такой Trac? Тогда я не понял, в чем заключается интеграция.

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

Это buildbot по триггеру?

Ну, в целом, да. Это общеизвестный и отлаженный билдбот по триггеру. Так-то «внешнее API» есть у многих, только вот пользоваться им далеко не всегда удобно.

По-моему, у вас большая группа разработчиков с развесистой инфраструктурой - я плохо представляю потребности таких групп.

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

Вообще, все эти технологии - это как, не знаю, вождение. Или плавание - один раз по-настоящему научившись, потом не представляешь, каково это - не уметь плавать. Или, - смешно сказать, - тонуть.

Смотри, например, https://android-review.googlesource.com/#/c/31100/ и то, как там можно посмотреть, что делалось в патчсетах с 1-го по 4 (на текущий момент)

Может, я чего-то не понимаю, но не впечатлен. Относительно base там изменен один файл, а относительно патчсетов 1-3 - километровый diff, не имеющий отношения к «Fix CalendarView CTS failures»

Ну, мны, вообще подобное можно использовать и в небольших или изолированных группах.

Как говорил Ларри Маквой, «если вас 3-5 человек, пофиг, что вы используете - tar с patch». Он, конечно, преувеличивал, но не сильно. Небольшая группа может довольно неплохо и долго жить без этого (хотя я понимаю, что автоматизация рулит).

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

AFAIK, с Trac аналогично.

Вообще, все эти технологии - это как, не знаю, вождение. Или плавание - один раз по-настоящему научившись, потом не представляешь, каково это - не уметь плавать

Не сыпь мне соль на всё подряд. Видишь в опросе 22%? Вот с такими людьми приходится работать. Для них вообще VCS недавно была ненужной непонятной сложностью (а для многих и осталась). Ты предлагаешь, чтобы я втюхал им Git? Серьезно?

Mercurial.

Git только в паре со SparkleShare (оно, увы, Mercurial не умеет).

А где monotone?

Какой ты нудный. Ну вот тебе практически копипаста: «List changesets mentioning „bug” or „issue” that are not in a tagged release».

git log --grep=«bug|issue» --not --tags

даже не смотрел в man

Твоя команда выдает список всех ревизий, у которых в комментариях нет «bug» или «issue», и которые при этом не являются тегами. Это не то, что нужно.

Нет, она выдаёт именно то что нужно - ревизии, у которых в комментариях ЕСТЬ bug или issue и которые не являются тэгами.

Еще раз - это не то, что нужно. «that are not in a tagged release» означает, что нужно вывести changeset-ы, не входящие в помеченный релиз, то есть те, среди потомков которых нет тегов.

Нет, именно это она и делает, почитайте описание --tags.

Ведь если архив в винде запаковать в zip и распаковать на линуксе - всё будет отображаться как надо...

а вот не тут то было

УМВР, ЧЯДНТ?

Хороший вариант решения, но что же мне делать чтобы посадить вендузятников на Mercurial, почему внутри Mercurial-а нельзя хранить названия файлов в UTF-8 и не парить мозг пользователю, просто конвертируя в нативную кодировку когда надо?

Потому что при кодировании из юникода возможна потеря информации, а кодирование в юникод одной и той же строки возможно сотнями способов, в итоге у вас будут произвольно меняться имена файлов и всё разломается. Zip может корёжить данные внутри себя как ему угодно, VCS же этого не простит.

И что же делать? Надо чтобы я в винде чем добавлял русско-названный файл и я его под Linux видел. Провел эксперимент с виртуальной машиной, все файлы добавлял исключительно через GUI - но нет, не сработало. В линуксе такие файлы с неверными именами.

Рекомендация разработчиков обещала что такой проблемы не будет если работать из GUI.

почитайте описание --tags.

Я прочитал. И даже попробовал:

$ git init
Initialized empty Git repository in /tmp/foo/.git/
$ date >>a; git add a
$ git commit -m"bugfix1"
Created initial commit 1b6ae12: bugfix1
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 a
$ date >>a; git add a
$ git commit -m"just work"
Created commit 141b925: just work
 1 files changed, 1 insertions(+), 1 deletions(-)
$ git tag rel1
$ date >>a; git add a
$ git commit -m"bugfix2"
Created commit 35f02ac: bugfix2
 1 files changed, 1 insertions(+), 1 deletions(-)
$ git log --grep=bug --not --tags
$

Вывод последней команды должен быть bugfix2.

Git, раньше был SVN.

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

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

«если вас 3-5 человек, пофиг, что вы используете - tar с patch»

Знаешь, если вас 3-5 человек, и больше не будет, то ваш жизненный цикл - год-два, потом по законам природы надо помирать. Тут действительно можно вообще ничего не использовать. Даже patch - излишество.

AFAIK, с Trac аналогично.

Я верю. Не совсем же они безнадёжны. Вопрос лишь в том, чтобы конкретными примерами показать мне, что Hg нормально интегрируется в остальную экосистему, а не так, как про это думаю я ;)

Вот с такими людьми приходится работать.

А, то есть, ты неофитов пришёл поокучивать, что те ксендзы Адама Козлевича? Не вопрос, прости, что влез.

Ты предлагаешь, чтобы я втюхал им Git? Серьезно?

Что-то мне подсказывает, что посылать тебя «продавать» Git - это всё равно, что топ-менеджеров Майкрософта отправлять торговать линуксом. Результат, как мы видели на примере истории Meego, немножко ниже нуля по Кельвину. Но это ничего не говорит за линукс, да?

А вообще, на прошедшей у нас двухнедельной летней школе, с задачей справились и студенты-третьекурсники. То есть, и понятием DSCM овладели, и герритом как инструментом кодерской коллаборации, и, вообще-то, бóльшую часть времени потратили не на тех.процесс, а на собственно программирование. Но, разумеется, это не пример, не.

Если ты хочешь, я продемонстрирую тебе, что такое история изменения патчсетов

Ну, если тебе нетрудно, продемонстрируй (и чтобы inline-комментарии сохранялись). А лучше скажи, почему в уже указанной тобой истории диффы от base и от patch set [1-3] такие разные.

Но, вообще-то, суть от этого не поменяется. Она, суть, в том, что

Суть я понимаю (ее понимает любой, кто делал ревью, которое не ограничилось одной итерацией).

если вас 3-5 человек, и больше не будет, то ваш жизненный цикл - год-два, потом по законам природы надо помирать.

«Есть много, друг Горацио» (ц)

Тут действительно можно вообще ничего не использовать. Даже patch - излишество.

Думаю, пойнт Ларри был в другом: даже примитивные средства вроде tar и patch могут сослужить очень хорошую службу по сравнению с их отсуствием (первые лет 10 развития ядра свидетельство тому пример).

Что-то мне подсказывает, что посылать тебя «продавать» Git - это всё равно, что топ-менеджеров Майкрософта отправлять торговать линуксом.

Линуксу не помешало бы иметь таких продажников, как у Майкрософта. Кстати, проверь свое «что-то» - спроси его, что бы я продал, если бы у меня был выбор между Git и SVN.

Вопрос лишь в том, чтобы конкретными примерами показать мне, что Hg нормально интегрируется

Нас его степень интеграции устраивает, нужно будет что-то более навороченное - будем смотреть. Судя по тому, что Mozilla спокойно сидит на Mercurial, и большие проекты с навороченным тестирование тоже интегрируются.

Но вообще-то примешивание интеграции в сравнение DVCS - сомнительный ход. Какой-нибудь TFS по интеграции зарулит всех в минуса.

ты неофитов пришёл поокучивать

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

на прошедшей у нас двухнедельной летней школе, с задачей справились и студенты-третьекурсники. То есть, и понятием DSCM овладели, и герритом как инструментом кодерской коллаборации

Верю. Особенно если это была первая DSCM, которой они овладели. И теперь у них синдром утенка.

Ну, если тебе нетрудно, продемонстрируй (и чтобы inline-комментарии сохранялись).

Мхм, вот, например, дифф [в единственном файле ] между 3-им и 4-ым патчсетами этого ченджсета. И можешь обратить внимание на комментарии к третьему патчсету, и то, как требуемые изменения были внесены в 4.

Вообще, если хочешь, там можно попереключаться между версиями прямо в начале странички. Учти только, что Base - это состояние ветки без твоих изменений, а патчсеты 1... - это то, как ты меняешь сорцы относительно базового состояния. И, если честно, я не вижу, где там

в уже указанной тобой истории диффы от base и от patch set [1-3] такие разные.

В первом патчсете автор сделал попытку безусловно обновлять в методе setMonthDisplayed() поле mCurrentMonthDisplayed и выставлять остальные связанные с этим полем члены класса. Уже во втором патчсете он от этой идеи отказался, но ввёл новое поле - mCurrentYearDisplayed. Следующие два патчсета были стилистическими правками (дифф между 2 и 4). Остались неясности?

Линуксу не помешало бы иметь таких продажников, как у Майкрософта.

Ну, если это было непонятно с первого раза, поясню ещё раз: продажник от Майкрософт по фамилии Элоп сделал всё, от него зависящее, чтобы [чуждая ему] платформа Миго сдохла. Она сдохла. Так что, не нужны Линуксу такие продажники, точно тебе говорю. Даже если майкрософтовые решения разлетаются у них, как горячие пирожки.

спроси его, что бы я продал, если бы у меня был выбор между Git и SVN.

Думаю, ты постарался свести бы дело к Hg :-)

Какой-нибудь TFS по интеграции зарулит всех в минуса.

Хы-хы. Щаз.. Тебе, наверное, не доводилось пользоваться, например, Проджектом в развесистом корпоративном енвайронменте. Это (по состоянию на конец 2008) - лютый п-ц был в плане распределённости. В свежих версиях, может, уже и полечили, но тогда в || это был ужас, по-другому не назовёшь.

но конкретно это был ответ на «вождение», «плавать», «тонуть» и автоматизацию процессов.

Ты меня так пытался переубедить?!

Верю. Особенно если это была первая DSCM, которой они овладели. И теперь у них синдром утенка.

Хых. Да, теперь они на Тёмной Стороне. У нас тут плюшки! Приходи и ты!

Судя по тому, что Mozilla спокойно сидит на Mercurial, и большие проекты с навороченным тестирование тоже интегрируются.

Справедливости ради, у Mozilla из важного только mozilla-central сидит на Mercurial, а новые/сторонние/экспериментальные проекты - все на GitHub :(

новые/сторонние/экспериментальные проекты - все на GitHub :(

В данном контексте это неважно.

«Ведь в главном-то он прав!» ;)

Ладно, в общем. Я знаю, что тебя по этому вопросу не переубедить, так, подначиваю беззлобно. В целом, я и Hg могу пользоваться без особых корч, но и любви при этом не испытываю, не к чему особо. Думал только, что ты мне какую киллер-фичу покажешь.

«Ведь в главном-то он прав!» ;)

Это да, но речь шла не о главном, а о б интеграции-шминтеграции.

Думал только, что ты мне какую киллер-фичу покажешь.

Реально киллер-фичой было появление появления локального коммита в системах 10-летней давности (хотя quilt был и раньше), а про то, чего мне не хватает в Git, писал уже не раз даже в этом топике. Ответа, кстати, не дождался :)

Ответа, кстати, не дождался :)

Вы там слишком долго препирались, чтобы оттуда можно было быстро вычленить задачу. Что там было-то? Только чур, не надо меня отправлять читать доку на revsets, у git-rev-list несколько другой входной язык, хотя, мне казалось, равномощный. evolve с виду похож на rebase -i, но ты же понимаешь, что равиоли с виду похожи на пельмени, а те, в свою очередь, на бурятские буузы.

Вы там слишком долго препирались, чтобы оттуда можно было быстро вычленить задачу. Что там было-то?

Не, объяснять снова у меня уже запала нет.

у git-rev-list несколько другой входной язык

Это не язык.

evolve с виду похож на rebase -i

rebase - это другое (хотя он тоже есть). evolve - инструмент коллективной работы, что-то вроде многопользовательского rebase + история патчсетов из gerrit, но на уровне VCS.