Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Мне как тимлиду не пофиг.
S>>А рациональное объяснение этому будет?

НС>Оно уже было. Мне важно знать реальную эволюцию кода, а не причесанную. Потому что, помимо собственно кода, с меня требуют, к примеру, чтобы сотрудники росли в профессиональном плане. И если у сотрудника слишком много опечаток это вполне повод поработать над его внимательностью или над тем как он коммиты делает.



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

Ты не конторой машинисток рулишь, судя по твоим постингам, а отделом программистов. Поэтому:

1. Для опечаток в современном мире есть IDE, которая и отлавливает всякие несогласованные скобки, и на типы сразу жалуется, и позволяет провести переименования по всему коду. Умение сотрудников использовать эти средства обеспечивается обучением и ловится по факту (можно просто наблюдать). И главное тут даже не то, что опечатки и глупые ошибки не должны уходить за пределы локального средства — а то, что если сотрудник умеет пользоваться IDE (что как раз ожидается от высокоуровневого сотрудника), ты просто не увидишь эти ошибки.

Да, не всё и не всегда отлавливается IDE. Может, у тебя основная нагрузка на какие-нибудь SQL операторы, а IDE не умеет их проверять. Тогда это уже к тебе, как к ПМ-у, вопрос, почему ты не обеспечил своих сотрудников качественными средствами разработки. Если надо купить, или разработать локально — это всё равно окупится.

2. Есть разнообразные pre-submit review средства вроде Gerrit. Достаточно быть подписанным на ревью своих подчинённых. Если видны любые ошибки на пробе, делать выводы можно и из них. Причём, если явно не стирать, все варианты предложений (patchsetʼы в его терминологии) с обсуждениями — хранятся вечно (в виде специально именованных веток в Git репе на сервере), можно поднять эту историю не хуже истории целевой ветки. И уже по этому можно судить о качестве работы сотрудника; я в нашей истории такие вещи вижу — например, принимается только 12-й patchset, а на первый страшно смотреть; в комментариях постоянные -2 (жёсткий запрет отправки), куча ругани от коллег на кривые подходы и реализацию => сразу видно, в чём и почему человеку надо расти. Естественно, даже простейшие количественные показатели типа количества patchset-ов (не включая внутренние ребейзы), комментариев, минусов в оценках и длительности от первого оценённого постинга до финала — могут быть автоматизированно подсчитаны (не забывать, что они только очень первичная прикидка к реальному качеству работы).

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

S>>>>Логично, если у вас в истории есть коммиты, ломающие сборку.
НС>>>Дело не в них. У нас редко бывает, что мы не знаем когда сломалось. Обычно сразу понятно какой коммит виноват, без бисекта.
S>>Ты не понял: очевидно, что ломающие сборку коммиты видно сразу (но только ты почему-то хочешь видеть их в мастере), дело в том, что они создают проблему при поиске других проблем (которые появились между коммитом X и Y).
НС>И часто у тебя такое бывает?

Если допускать в постоянную историю коммиты, которые не проверены настолько, что в них есть даже опечатки — это происходит постоянно. Если у тебя не так, то у тебя или роботы (не верю), или проверка происходит до сабмита, или ты где-то лукавишь.

Для типовых юз-кейсов вполне простой инструмент, возможно даже проще для понимания, чем всякие ГУЙ-ориентированные перфорсы.
Потребности "посмотреть все, что случилось с файлом" никогда не было.

Кстати, если почитать рекламную брошюру к helix-core, они все время себя сравнивают с git, т.е. git это сейчас стандарт де факто, эталон.

Здравствуйте, Skorodum, Вы писали:

S>git почему-то является камнем предкновения для многих разработчиков

git — как ассемблер x86. Полторы тысячи команд, из которых треть уже никто не помнит, для чего были нужны, но выкинуть нельзя, еще треть никто пока не знает, для чего они будут нужны, а функциональность остальных причудливым образом пересекается и перекрывается, и какую именно команду надо использовать для того или иного случая, никто не знает и не может объяснить.

Здравствуйте, Pzz, Вы писали:

S>>git почему-то является камнем предкновения для многих разработчиков

Pzz>git — как ассемблер x86. Полторы тысячи команд, из которых треть уже никто не помнит, для чего были нужны, но выкинуть нельзя, еще треть никто пока не знает, для чего они будут нужны, а функциональность остальных причудливым образом пересекается и перекрывается, и какую именно команду надо использовать для того или иного случая, никто не знает и не может объяснить.

"Проблемы" только в тех случаях, когда есть много способов сделать один и тот же результат потому, что это вообще возможно. Например, выбрать ветку A и смержить в неё B, или выбрать B и смержить в неё A? Как лучше есть бутерброд — колбасой вверх или вниз?

Здравствуйте, netch80, Вы писали:

N>"Проблемы" только в тех случаях, когда есть много способов сделать один и тот же результат потому, что это вообще возможно. Например, выбрать ветку A и смержить в неё B, или выбрать B и смержить в неё A? Как лучше есть бутерброд — колбасой вверх или вниз?

Ну конечно колбасой вниз. Ты что, Простоквашино не смотрел?

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, netch80, Вы писали:

N>>"Проблемы" только в тех случаях, когда есть много способов сделать один и тот же результат потому, что это вообще возможно. Например, выбрать ветку A и смержить в неё B, или выбрать B и смержить в неё A? Как лучше есть бутерброд — колбасой вверх или вниз?

Pzz>Ну конечно колбасой вниз. Ты что, Простоквашино не смотрел?

Смотрел, поэтому и намекаю

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, Skorodum, Вы писали:

S>>git почему-то является камнем предкновения для многих разработчиков

Pzz>git — как ассемблер x86. Полторы тысячи команд, из которых треть уже никто не помнит, для чего были нужны, но выкинуть нельзя, еще треть никто пока не знает, для чего они будут нужны, а функциональность остальных причудливым образом пересекается и перекрывается, и какую именно команду надо использовать для того или иного случая, никто не знает и не может объяснить.

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

Здравствуйте, Ватакуси, Вы писали:

В>>>не для средних умов
BFE>>Любая система управления версиями — не для средних умов, потому что задача сложная.
В>Вышеуказанная Hg+черепаха как-то справляются и для средних умов страданий не наблюдается.

Странно, мой куцый опыт показывает что это не так.
Как-то помогал с проектом в котором использовался "hg".
Проект который там писался основан довольно на нетривиальной математике,
и они в ней неплохо разбирались, но слить мои изменения со своими они не смогли,
потому что имели опыт работы только с один из N способов ведения веток в "hg".
И пришлось им даже присылать скриншоты что тыкать в черепахе чтобы все нормально
замерджилось, так как надо было срочно.

С тех пор остался вопрос почему в средстве которым "легко" пользоваться столько
способов ведения веток и почему там все настолько интуитивно непонятно устроенно по
сравнению с git.

Здравствуйте, student__, Вы писали:

__>Потребности "посмотреть все, что случилось с файлом" никогда не было.
Если у вас не было, то это не значит, что у других такой потребности не было.

Здравствуйте, Ватакуси, Вы писали:

В>Ведь ломкое, не для средних умов и относительно нормально работает только в консоли. Ужас.

А что там не для средних умов если пользоваться теми же функциями как в SVN например.
Но удобнее SVN в том что можно одной командой создать локальный репозиторий и начать в нем работать,
не дожидаясь когда Вася админ выполнит заявку и создаст репозиторий в организации или не создавая лишних репозиториев на github пока не будет какого-то рабочего варианта.

Здравствуйте, okon, Вы писали:

O>Здравствуйте, Ватакуси, Вы писали:

В>>Ведь ломкое, не для средних умов и относительно нормально работает только в консоли. Ужас.

O>А что там не для средних умов если пользоваться теми же функциями как в SVN например.
O>Но удобнее SVN в том что можно одной командой создать локальный репозиторий и начать в нем работать,

Хм, вроде в обоих системах одно и тоже,
в плане работы с локальным репозиториями я имею ввиду:

svnadmin create repo1
svn mkdir file:///var/repos/localsvn/repo1/trunk -m "make trunk"
svn co file:///var/repos/localsvn/repo1/trunk ~/projects/repo1trunk
svn commit -m "1st commit"

Ну и тоже самое с "git": "git init", "git clone"..

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>С CVS или SourceSafe и его клонами доводилось работать?

Зачем пытаться сравнивать DVCS с классическими, да еще и очень древними?
Может сравнивать различные DVCS между собой? Убогий-косой-кривой Git с могучим-быстрым-сверкающим Mercurial?

После чего сходить посмотреть, какие проекты и компании отказались от Git или перманентно или по опыту, в пользу Mercurial?

Здравствуйте, Zhendos, Вы писали:

Z>Здравствуйте, okon, Вы писали:

O>>Здравствуйте, Ватакуси, Вы писали:

В>>>Ведь ломкое, не для средних умов и относительно нормально работает только в консоли. Ужас.

O>>А что там не для средних умов если пользоваться теми же функциями как в SVN например.
O>>Но удобнее SVN в том что можно одной командой создать локальный репозиторий и начать в нем работать,

Z>Хм, вроде в обоих системах одно и тоже,
Z>в плане работы с локальным репозиториями я имею ввиду:

Z>

Z>svnadmin create repo1
Z>svn mkdir file:///var/repos/localsvn/repo1/trunk -m "make trunk"
Z>svn co file:///var/repos/localsvn/repo1/trunk ~/projects/repo1trunk
Z>svn commit -m "1st commit"
Z>

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

Здравствуйте, Zhendos, Вы писали:

O>>А что там не для средних умов если пользоваться теми же функциями как в SVN например.
O>>Но удобнее SVN в том что можно одной командой создать локальный репозиторий и начать в нем работать,
Z>Хм, вроде в обоих системах одно и тоже,
Z>в плане работы с локальным репозиториями я имею ввиду:
Не совсем. Разницу ощутишь, когда ты ВНЕЗАПНО таки захочешь этот свой локальный репозиторий отдать куда-то. В случае git ты просто дождёшься когда админ создаст новую репо и туда сделаешь push, а в случае svn — упс.

Здравствуйте, ·, Вы писали:

·>Не совсем. Разницу ощутишь, когда ты ВНЕЗАПНО таки захочешь этот свой локальный репозиторий отдать куда-то. В случае git ты просто дождёшься когда админ создаст новую репо и туда сделаешь push, а в случае svn — упс.

Непонятно в чем будет "упс".
Я вижу по крайней мере два простых пути:

1) Запускаешь локально "svnadmin dump", и отсылаешь админу, он делает "svnadmin load" и все.
Эта процедура должна быть прекрасно знакома админу, ведь с помощью нее делается бэкап svn.
2) Также просишь админа создать пустой репозиторий, делаешь
svn diff / svn log , чтобы сохранить все коммиты в файлы типа "rN.txt",
а потом с помощью "svn commit" отправляешь все это на сервер.
Благодаря глобальному целому счетчику коммитов такой скрипт думаю
строк 10 на bash займет.

Здравствуйте, a7d3, Вы писали:

SVZ>>С CVS или SourceSafe и его клонами доводилось работать?

A>Зачем пытаться сравнивать DVCS с классическими, да еще и очень древними?

Гм, на их фоне что Свин, что Гит очень даже "могучие-быстрые-сверкающие" (с).

A>Может сравнивать различные DVCS между собой? Убогий-косой-кривой Git с могучим-быстрым-сверкающим Mercurial?

У меня к Гиту претензий нет. Все наши задачи он решает. А Меркуриал даже посмотреть нигде не довелось.

A>После чего сходить посмотреть, какие проекты и компании отказались от Git или перманентно или по опыту, в пользу Mercurial?

Окей, давай сходим. Где это можно посмотреть?

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Здравствуйте, a7d3, Вы писали:


A>>Может сравнивать различные DVCS между собой? Убогий-косой-кривой Git с могучим-быстрым-сверкающим Mercurial?

SVZ>У меня к Гиту претензий нет. Все наши задачи он решает. А Меркуриал даже посмотреть нигде не довелось.

Это плохо, когда не знаешь альтернатив, элементарно, в том же классе решений.


A>>После чего сходить посмотреть, какие проекты и компании отказались от Git или перманентно или по опыту, в пользу Mercurial?

SVZ>Окей, давай сходим. Где это можно посмотреть?

Проекты? Да мелочь всякая, никому неизвестная: OpenJDK, NetBeans, Mozilla, Nginx ...
https://www.mercurial-scm.org/wiki/ProjectsUsingMercurial
https://en.wikipedia.org/wiki/Mercurial#Open_source_projects_using_Mercurial

Компании? Дурацкие стартапы, вроде Facebook, https://engineering.fb.com/core-data/scaling-mercurial-at-facebook/

Здравствуйте, a7d3, Вы писали:

A>>>Может сравнивать различные DVCS между собой? Убогий-косой-кривой Git с могучим-быстрым-сверкающим Mercurial?

SVZ>>У меня к Гиту претензий нет. Все наши задачи он решает. А Меркуриал даже посмотреть нигде не довелось.

A>Это плохо, когда не знаешь альтернатив, элементарно, в том же классе решений.

Лучшее — враг хорошего.
Мы лет 10 назад перевели исходники из "Code Co-op" в Гит и закрыли все наши потребности. Гитхаб полностью справляется с нашими хотелками.
Что нам даст Меркуриал? Понятия не имею.

A>>>После чего сходить посмотреть, какие проекты и компании отказались от Git или перманентно или по опыту, в пользу Mercurial?
SVZ>>Окей, давай сходим. Где это можно посмотреть?

A>Проекты? Да мелочь всякая, никому неизвестная: OpenJDK, NetBeans, Mozilla, Nginx ...
A>Компании? Дурацкие стартапы, вроде Facebook, https://engineering.fb.com/core-data/scaling-mercurial-at-facebook/

В здравом уме никто просто так не мигрирует из одной VCS в другую.
У них, безусловно, были причины для перехода.
Из твоей статьи Мордокнига использовала Меркуриал не из коробки, а обрабатывала его напильником под свои нужды.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Здравствуйте, a7d3, Вы писали:

A>>Это плохо, когда не знаешь альтернатив, элементарно, в том же классе решений.

SVZ>Лучшее — враг хорошего.
SVZ>Мы лет 10 назад перевели исходники из "Code Co-op" в Гит и закрыли все наши потребности. Гитхаб полностью справляется с нашими хотелками.
SVZ>Что нам даст Меркуриал? Понятия не имею.

Дык по той же логике 20 лет назад люди сидели на CVS и SourceSafe, и тоже самое говорили про Perforce & Subversion.
«Какой смысл выходит из дома, если все равно каждый день возвращаешься обратно?» (с) Симпсоны
Зачем нам С++11, когда и С++03 хватает? Зачем нам С++14? Зачем нам С++17? Зачем нам С++20?
Нам и так неплохо, наши потребности закрывает, а лучше — враг хорошего.

A>>>>После чего сходить посмотреть, какие проекты и компании отказались от Git или перманентно или по опыту, в пользу Mercurial?
SVZ>>>Окей, давай сходим. Где это можно посмотреть?

A>>Проекты? Да мелочь всякая, никому неизвестная: OpenJDK, NetBeans, Mozilla, Nginx ...
A>>Компании? Дурацкие стартапы, вроде Facebook, https://engineering.fb.com/core-data/scaling-mercurial-at-facebook/

SVZ>В здравом уме никто просто так не мигрирует из одной VCS в другую.
SVZ>У них, безусловно, были причины для перехода.
SVZ>Из твоей статьи Мордокнига использовала Меркуриал не из коробки, а обрабатывала его напильником под свои нужды.

И делали это не от жизни хорошей, а потому что на Git'е им жизни не было.
Собственно, сам Mercurial от этого их внимания лишь только выиграл.