Мэтт устал и уходит

Не видел чтобы это пытались совмещать.

Ну тикеты в баг-трекере удобно связвать с конкретными коммитами, которые их закрывают.

Или например указывать что такой-то коммит вызывает какую-то проблему в тикете.

У нас svn частенько херил коммиты когда 2 человека работали над одним кодом. Рабочее время потом тратится на разборки что где.

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

Место стикера на доске указывает на статус этого стикера. Во время выступления на скрам-митинге («я вчера запилил то-то и то-то, а сегодня будут фигачить вот это») соответствующие стикеры переклеиваются со старого места на новое. Первая нагуглившасяся фотка: http://www.xqa.com.ar/visualmanagement/wp-content/gallery/general-pictures/bo... Тысяч стикеров не наблюдаю.

У нас svn частенько херил коммиты когда 2 человека работали над одним кодом.

Лолшто? Может, эти два «человека» просто не озабачивались мерджить свои правки с чужими (и вместо нормального мерджа чужие правки просто отьбрасывали)?

В комментарии к коммиту ссылаешься на баг

Делается в Kallithea

А для чего это нужно <...>?

Примерно для того же, для чего нужны обычные версии. Человеку понятнее, что rev309 была раньше, чем rev311. Взаиморасположение 62be0bc106 и 35f5dd274d не так очевидно.

и почему это нельзя решить хуком в git?

А как это решить хуком в git? inb4: история в git ветвится, в разных ветках может быть разное число коммитов, поэтому число изменений по пути от самого первого до текущего меняется в зависимости от пути, который выбираешь.

было бы классно если Мэтт позвонил бы в офис Git, и поздравил с победой.

тыщей способов

Пример?

вплоть до подсчета количества коммитов в ветке, к примеру.

Число зависит от выбранной точки старта и пути к текущей точке.

Тысяч стикеров не наблюдаю.

Намекну: размер проекта, количество команд и участников. Доска это конечно хорошо, но это более медленный, менее наглядный и менее удобный в пользовании способ организации. Сойдёт чтобы попонтоваться или если нет электричества, но как способ работы — лучше убейте. Серьёзно, мне раз пришлось попробовать такие стикеры.

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

Для вменяемых размеров команды (не больше 6 разрабов, не больше 6 тестеров, аналитик, манагер) физическая доска гораздо нагляднее и удобнее. А другим командам детали чужого спринта должны быть не интересны.

Сойдёт чтобы попонтоваться или если нет электричества, но как способ работы — лучше убейте. Серьёзно, мне раз пришлось попробовать такие стикеры.

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

Ну не знаю, видимо это субьективно. Я ни разу не ощущал проблем от электронной системы, а вот с бумажной хватило.

Нет. Все делали по уму. А вендовая херня черепашка (афайк просто гуйня к svn) перезаписывала коммиты прям поверх. Не каждый раз, но в зависимости от фазы луны.

А вендовая херня
вендовая

Должны страдать.

Для еще более многих git слишком сложен.

А для немногих неприятен: система команд делалась без какой-либо идеи, историческим способом. Т.е. git неприятная субстанция, но де факто стандарт в опенсоурс, как лет 20 назад был cvs, который тоже уже тогда попахивал.

Примерно для того же, для чего нужны обычные версии. Человеку понятнее, что rev309 была раньше, чем rev311.

Да это очевидно.

Взаиморасположение 62be0bc106 и 35f5dd274d не так очевидно.

Совсем не очевидно. Но зачем это нужно? Почему нельзя посмотреть лог с датой коммита?

А как это решить хуком в git? inb4: история в git ветвится, в разных ветках может быть разное число коммитов, поэтому число изменений по пути от самого первого до текущего меняется в зависимости от пути, который выбираешь.

Вести сквозную нумерацию, как в subversion, не оглядываясь на ветки?

Число зависит от выбранной точки старта и пути к текущей точке.

Если с учетом пути, то в качестве старта брать первый коммит. Если без учета пути, то хуком инкрементить номер коммита.

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

Я знаю только единственного Hg пользователя tailgunner.

еще я есть (но совсем-совсем не фанбой, и вообще меня заставили).

добровольно только git ессно.

А как это решить хуком в git? inb4: история в git ветвится, в разных ветках может быть разное число коммитов, поэтому число изменений по пути от самого первого до текущего меняется в зависимости от пути, который выбираешь.

Обычно на прод и найтбилды выкатывают _только_ из тегов. Для того они и созданы. Это сильно упрощает ситуацию отлова багов в продакшене. А в разработке, как уже выше сказали всегда можно лог посмотреть, где есть таймстампы и деревов коммитов.

Вести сквозную нумерацию, как в subversion, не оглядываясь на ветки?

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

Все эти решения содержат элемент «ну как-то так», который всегда разбивается о реальность.

svn архитектурно не может потерять коммиты. Всё что написано пером, не вырубишь топором. Аналога «git push --force» там нет. Так что ты явно что-то недоговариваешь.

Скрам-доска на тысячу стикеров? facepalm.xcodeproject

Тебе смешно, а я реально видел доску где на полгода вперёд запланированы все таски. Эта доска занимала всю стену и люди в процессе планирования в очередь выстраивались чтобы бумажку прицепить. В итоге решили что эти стикеры — бесполезные понты.

так это, аналитикам-то с дивана-то вяднее

Вотпрямщас вижу своими глазами svn в Loewe.

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

никогда не видел его в употреблении кроме каких-то упоротых ссзб опенсорц проектов

вот так взял и обобщил https://www.mercurial-scm.org/wiki/ProjectsUsingMercurial

есть svn и git

Тут надо обратиться к истокам: откуда взялся git, и что сподвигло Линуса на такой лютый велосипедизм и острый NIH-синдром как написание своей дистрибутед вершын контрол систем с хэшами и пулл-реквестами. Потому что гита не было — и как-то жили :) А когда гит насильственно внедряется пер ректум или down your throat — отличный способ парализовать работу, даже обмазавшись гайдлайнами и инструкциями :)

«Шта?» (с)

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

Доска на полгода вперёд – это классическое «научи дурака богу молиться».

Да, «вяднее», потому что то что ты написал невозможно даже в теории, достаточно хоть немного знать про устройство svn.

Потеря коммитов – это как раз особенность git. Потому что дерево коммитов легко модифицировать.

Вот и получается, что ни git, ни svn ты толком не знаешь, а потяфкать пришёл. Классический git-фанбой.

и почему я раньше думал, что ты адекватный...

Да, «вяднее», потому что то что ты написал невозможно даже в теории

Он имел в виду потерю состояния рабочей копии, просто слов подходящих не знает.

Взаимно.

Ну это ж не по эджайлу совсем.

Agile это общее название. Их over 9000 разновидностей, и у каждой своя гениальная идея, как повысить работоспособность в 500 раз путём перестановки людей местами.

Карго-культизма никто не отменял.

Все эти решения содержат элемент «ну как-то так», который всегда разбивается о реальность.

Моя реальность такова - мне фиолетово на сквозную нумерацию сабвершна. Мне не приходится городить костыли поверх гит.

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

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

Если они твои личные, почему не сконвертируешь в Git?

Если они твои личные, почему не сконвертируешь в Git?

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

Почему жаль? По-моему, всё только к лучшему. Совет разработчиков сможет принимать более компетентные решения, чем один-единственный человек (я тоже пользователь Hg, если что).

Kallithea.

Kallithea.

есть опыт использования? Какие впечатления?

Почему жаль?

Мэтт устал и уходит (комментарий)

Это ИМХО

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

Если совет хорошо самоорганизован, либо у него хороший лидер (председатель/генсек/етц...)

есть опыт использования?

Есть, в личных целях. Очень сильно не хватает issue-трекера, но в целом, нормальная вещь.

Очень сильно не хватает issue-трекера

Wiki:

Kallithea is a cross-platform free software source code management system, the primary goal of which is to provide a repository hosting service with features for collaboration, such as forking, pull requests, code review, issue tracking

Что ты понимаешь под «issue-трекер»?

https://kallithea-scm.org/repos/kallithea

интересно, по какому признаку отсортированы Latest Changes?.. Что-то такая система уже не вызывает доверия...

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

Смотря какой совет и какой человек.

Два чая вам. Ну и UI в виде Stash/Crucible/etc. для удобного code review. В Stash подкупает возможность мержа только после успешного ревью изменений в ветке.

http://docs.kallithea-scm.org/en/latest/setup.html#integration-with-issue-tra...

Встроенного трекера нет, нужно поднимать его отдельно.

последнее закрытое

Kallithea — это форк Rhodecode, кстати, который откололся, когда последний стал проприетарным.

Встроенного трекера нет, нужно поднимать его отдельно.

печаль-беда... :(

Число зависит от выбранной точки старта и пути к текущей точке.

Дык вы релизы из одной веточки-то делайте - и болеть не будет. Гит флоу, все дела.

Однако точно. В Зименс и Филипс только svn и используют.