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

V>>>Pull requests — это исключительно и только про code review.
V>·>Нет, не только. Это в общем случае обмен contributions to a project.
V>Обмен наработками делается через push.
V>А в этом сценарии через code review.
Чтобы сделать push — надо иметь full access repo, в отличие от pull requests. Совсем другая модель.

V>>>Он работает с произвольными бранчами и произвольными репозиториями.
V>·>Без центрального веб-сервера web review как-то странно работает.
V>Без сервера git он не работает.
V>Файлового или сетевого.
V>Ты не можешь отправить pull request в космос, ты отправляешь его через репозиторий.
Ты можешь свой репозиторий расшарить readonly. Без какого-либо центрального места куда должны ломиться все в случае того же review board, должны быть админы, которые раздают права и решают кто достоин, кто нет, кто, что и как должен делать и т.п. Всё внезапно становится centralised.

V>·>Как работать с произвольными бранчами и репозиториями для cvs/svn — вообще загадка.
V>Так же.
V>Существовали тулзины для синхронизации репозиториев.
V>У нас была самописная аналогичная когда-то, там нефик делать.
Но это будут не произвольные бранчи/репозитории. Надо будет сделать кучу соглашений и продумать всякие сценариии, чтобы это всё не накрылось и не пришлось вручную что-то как-то восстанавливать. Понятно, что и зайца можно научить курить...

V>>>Не только. В git хранятся в том числе revlog-и, для целей экономии места.
V>·>Это что?? reflog имеешь в виду? Или delta compression ты так называешь?
V>Последнее.
Но delta compression не имеет практически ничего общего с revlogs.

V>·>Почему не сделали? Много всяких сайтов, на которых были и git и другие vcs.
V>ИМХО, потому что mercurial больше похож на коммерческую VCS.
Почему похож? И что это вообще значит? Очередная отмаза?
Мало того. помимо mercurial были всякие bazaar, darcs и т.п.

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

V>А git связан кровным родством с надёжным, в плане направления исключительно опенсорса, ядром линухов.
А мне кажется, что наоборот — git как раз и возник с целью тянуть этот самый опенсорс линух. Другие vcs просто не справлялись, потому что их делали не из практических нужд, а чтобы что-нибудь продать "у нас крутая система плагинов и вообще питон рулит!".

V>К тому же, когда разработчики ядра его юзают в постоянной работе, это означало, что даже если в какой-нибудь конкретный момент git где-то слаб, то в перспективе его допилят до нормального состояния. Т.е. это не факт и не факт, что конкурентов не допилят, но психологический фактор тоже не из последних.
А mercurial использовать для больших популярных проектов было запрещено законодательно или что?

V>Ну и, положа руку на, способы хранения данных в VCS можно развивать от версии к версии.
V>Собсно, эти способы и развивались по-факту что в git, что в hg.
Детали реализации да — улучшить алгоритмы компрессии — да, можно, но не сама основа дизайна:
Mercurial or bazaar are FILE VCS (they store versions of files), and distributed.
Git is a CONTENT VCS (it stores delta of content, not the file itself: two files with the same content will be stored only once)

V>>>Можно сказать "заточен под определённые сценарии".
V>·>Которых не хватает. А расширяемость модели хранилища — никакущая.
V>В опенсорсе всё работает на обратной связи.
V>Была бы соответствующая популярность и соответствующие запросы — давно бы всё было сделано.
V>Так-то гит уже относительно немолодой, но более-менее зрелым стал буквально 3-4 года назад.
А svn сразу был идеален? Вспомнить как оно в каждую папочку клало .svn и рабочая копия внезапно вырастала по размеру в разы... А какие красивые были success story, когда после переезда внезапно размер рабочей копии git с полной историей был в неск. раз меньше, чем svn без истории.

V>>>Не вижу проблем, когда code review добавляет инкрементальные изменения.
V>>>Не надо стесняться быть иcправленным! ))
V>·>Дело вкуса.
V>А иногда исправление показывает на какую-нить популярную ошибку.
V>Ведь чаще ревью делает более опытный разработчик, чем автор (не обязательно, но очень часто именно так).
V>Сохранение таких исправлений само по себе является наглядным пособием и способно дать пищу для размышлений другим коллегам.
Логи код-ревью обычно остаются публичными. Но это не означает, что они должны засирать основную vcs историю.

V>>>А вот когда что-то меняется задним числом — вижу тут сразу несколько проблем.
V>>>В первую очередь это вероятность прохождения волны конфликтов при обновлении коммитов (в логическом их смысле, ага).
V>·>Для куска под code review?
V>Почему нет, если текущая ветка успела "убежать", пока у ревьювера дошли руки?
_Волны_? Вот это непонятно. Ну да, куску придётся догнать убежавшую ветку, но это, как правило, не является чем-то сложным.
Волна возникает, когда на ребейзнутой ветке уже кто-то что-то успел наплодить, а потом ещё и ещё. Но так всё-таки обычно никто не делает.

V>>>>>И точно так же можно посмотреть diff перед этим rebase-merge.
V>>>·>А что если я что-то забыл, ошибся, слажал, и пришлось посмотреть diff уже после rebase-merge-whatever? "Сам дурак! Раньше надо было думать!" — ответ hg, "да, пожалуйста" — ответ git.
V>>>А чем hg revert не устраивает? Или hg rollback?
V>·>Просто для того, чтобы почитать diff?? Ты серьёзно?
V>diff можно посмотреть в любой момент м/у любыми ревизиями или для 3-хстороннего мержа.
В этом и проблема, что всякие эти плагины не делают ревизий. stash хранится где-то в стороне, и ревизий у них нет. Так же после rebase старое содержимое уходит куда-то в bundle, и ревизий опять нет (я не в курсе последних новостей, но раньше было именно так). И это всё потому, что revlog диктует свои ограничения (а delta compression вообще никак не влияет).

V>·>Я ничего не понял, причём тут это? А что, в hg/svn/etc это всё искаропки и их протокол всё такое поддерживает?
V>Да, сам hg заточен на расширение плагинами и его протокол расширяемый как опциями компрессии, так и содержимым:
V>

V>extensible for new features (required and optional)

Ты от вопроса не уходи. Как то что ты там понаписал выше "git не умеет" реализуется в hg на базе его супер-расширяемого супер-плагинами супер-протокола? Ну например "комментировать/обсуждать строчки diff коммитов"?

V>·>Не то что политика sf — вот уж где гениальнейший бизнес-план!
V>А что не так было с политикой sf тем более в конце 90-х? ))
V>Поначалу это было весьма простенький сайт с поиском проектов по их названию и технологиям, на которых они сделаны.
V>Тогда даже еще не было такой вещи как "ключевые слова для поиска", помнится.
V>В общем, в sf никто никогда особо не вкладывался, это весьма недорогой в разработке и поддержке проект.
Ну вначале да, а потом они решили делать деньги: In July 2013 SourceForge announced that it would provide project owners with an optional feature called DevShare, which places closed-source ad-supported content into the binary installers and gives the project part of the ad revenue. Идиоты. Результат немного предсказуем: In response to the DevShare adware many users and projects migrated to GitHub, other software hosting facilities, or self-host their software.

V>Другое дело гитхаб — это высококлассный коммерческий уровень, доступный нахаляву.
V>Там только на ЗП 800 человекам по самым скромным подсчётам требуется 6-8 лямов $$ ежемесячно.
Для системы такого масштаба — неудивительно.

V>>>Этот проект был создан не для зарабатывания, а для вытеснения зарабатывающих.
V>·>Т.е. github под конец весь разорился и все умерли. Happy end.
V>350 лямов денег подарили...
Как же... подарили... Инвестировали.

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

V>>>Pull requests — это исключительно и только про code review.
V>·>Нет, не только. Это в общем случае обмен contributions to a project.
V>Обмен наработками делается через push.
V>А в этом сценарии через code review.
Чтобы сделать push — надо иметь full access repo, в отличие от pull requests. Совсем другая модель.

V>>>Он работает с произвольными бранчами и произвольными репозиториями.
V>·>Без центрального веб-сервера web review как-то странно работает.
V>Без сервера git он не работает.
V>Файлового или сетевого.
V>Ты не можешь отправить pull request в космос, ты отправляешь его через репозиторий.
Ты можешь свой репозиторий расшарить readonly. Без какого-либо центрального места куда должны ломиться все в случае того же review board, должны быть админы, которые раздают права и решают кто достоин, кто нет, кто, что и как должен делать и т.п. Всё внезапно становится centralised.

V>·>Как работать с произвольными бранчами и репозиториями для cvs/svn — вообще загадка.
V>Так же.
V>Существовали тулзины для синхронизации репозиториев.
V>У нас была самописная аналогичная когда-то, там нефик делать.
Но это будут не произвольные бранчи/репозитории. Надо будет сделать кучу соглашений и продумать всякие сценариии, чтобы это всё не накрылось и не пришлось вручную что-то как-то восстанавливать. Понятно, что и зайца можно научить курить...

V>>>Не только. В git хранятся в том числе revlog-и, для целей экономии места.
V>·>Это что?? reflog имеешь в виду? Или delta compression ты так называешь?
V>Последнее.
Но delta compression не имеет практически ничего общего с revlogs.

V>·>Почему не сделали? Много всяких сайтов, на которых были и git и другие vcs.
V>ИМХО, потому что mercurial больше похож на коммерческую VCS.
Почему похож? И что это вообще значит? Очередная отмаза?
Мало того. помимо mercurial были всякие bazaar, darcs и т.п.

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

V>А git связан кровным родством с надёжным, в плане направления исключительно опенсорса, ядром линухов.
А мне кажется, что наоборот — git как раз и возник с целью тянуть этот самый опенсорс линух. Другие vcs просто не справлялись, потому что их делали не из практических нужд, а чтобы что-нибудь продать "у нас крутая система плагинов и вообще питон рулит!".

V>К тому же, когда разработчики ядра его юзают в постоянной работе, это означало, что даже если в какой-нибудь конкретный момент git где-то слаб, то в перспективе его допилят до нормального состояния. Т.е. это не факт и не факт, что конкурентов не допилят, но психологический фактор тоже не из последних.
А mercurial использовать для больших популярных проектов было запрещено законодательно или что?

V>Ну и, положа руку на, способы хранения данных в VCS можно развивать от версии к версии.
V>Собсно, эти способы и развивались по-факту что в git, что в hg.
Детали реализации да — улучшить алгоритмы компрессии — да, можно, но не сама основа дизайна:
Mercurial or bazaar are FILE VCS (they store versions of files), and distributed.
Git is a CONTENT VCS (it stores delta of content, not the file itself: two files with the same content will be stored only once)

V>>>Можно сказать "заточен под определённые сценарии".
V>·>Которых не хватает. А расширяемость модели хранилища — никакущая.
V>В опенсорсе всё работает на обратной связи.
V>Была бы соответствующая популярность и соответствующие запросы — давно бы всё было сделано.
V>Так-то гит уже относительно немолодой, но более-менее зрелым стал буквально 3-4 года назад.
А svn сразу был идеален? Вспомнить как оно в каждую папочку клало .svn и рабочая копия внезапно вырастала по размеру в разы... А какие красивые были success story, когда после переезда внезапно размер рабочей копии git с полной историей был в неск. раз меньше, чем svn без истории.

V>>>Не вижу проблем, когда code review добавляет инкрементальные изменения.
V>>>Не надо стесняться быть иcправленным! ))
V>·>Дело вкуса.
V>А иногда исправление показывает на какую-нить популярную ошибку.
V>Ведь чаще ревью делает более опытный разработчик, чем автор (не обязательно, но очень часто именно так).
V>Сохранение таких исправлений само по себе является наглядным пособием и способно дать пищу для размышлений другим коллегам.
Логи код-ревью обычно остаются публичными. Но это не означает, что они должны засирать основную vcs историю.

V>>>А вот когда что-то меняется задним числом — вижу тут сразу несколько проблем.
V>>>В первую очередь это вероятность прохождения волны конфликтов при обновлении коммитов (в логическом их смысле, ага).
V>·>Для куска под code review?
V>Почему нет, если текущая ветка успела "убежать", пока у ревьювера дошли руки?
_Волны_? Вот это непонятно. Ну да, куску придётся догнать убежавшую ветку, но это, как правило, не является чем-то сложным.
Волна возникает, когда на ребейзнутой ветке уже кто-то что-то успел наплодить, а потом ещё и ещё. Но так всё-таки обычно никто не делает.

V>>>>>И точно так же можно посмотреть diff перед этим rebase-merge.
V>>>·>А что если я что-то забыл, ошибся, слажал, и пришлось посмотреть diff уже после rebase-merge-whatever? "Сам дурак! Раньше надо было думать!" — ответ hg, "да, пожалуйста" — ответ git.
V>>>А чем hg revert не устраивает? Или hg rollback?
V>·>Просто для того, чтобы почитать diff?? Ты серьёзно?
V>diff можно посмотреть в любой момент м/у любыми ревизиями или для 3-хстороннего мержа.
В этом и проблема, что всякие эти плагины не делают ревизий. stash хранится где-то в стороне, и ревизий у них нет. Так же после rebase старое содержимое уходит куда-то в bundle, и ревизий опять нет (я не в курсе последних новостей, но раньше было именно так). И это всё потому, что revlog диктует свои ограничения (а delta compression вообще никак не влияет).

V>·>Я ничего не понял, причём тут это? А что, в hg/svn/etc это всё искаропки и их протокол всё такое поддерживает?
V>Да, сам hg заточен на расширение плагинами и его протокол расширяемый как опциями компрессии, так и содержимым:
V>

V>extensible for new features (required and optional)

Ты от вопроса не уходи. Как то что ты там понаписал выше "git не умеет" реализуется в hg на базе его супер-расширяемого супер-плагинами супер-протокола? Ну например "комментировать/обсуждать строчки diff коммитов"?
Да, кстати, в git такое делается и без всякой магической расширяемости: https://github.com/google/git-appraise

V>·>Не то что политика sf — вот уж где гениальнейший бизнес-план!
V>А что не так было с политикой sf тем более в конце 90-х? ))
V>Поначалу это было весьма простенький сайт с поиском проектов по их названию и технологиям, на которых они сделаны.
V>Тогда даже еще не было такой вещи как "ключевые слова для поиска", помнится.
V>В общем, в sf никто никогда особо не вкладывался, это весьма недорогой в разработке и поддержке проект.
Ну вначале да, а потом они решили делать деньги: In July 2013 SourceForge announced that it would provide project owners with an optional feature called DevShare, which places closed-source ad-supported content into the binary installers and gives the project part of the ad revenue. Идиоты. Результат немного предсказуем: In response to the DevShare adware many users and projects migrated to GitHub, other software hosting facilities, or self-host their software.

V>Другое дело гитхаб — это высококлассный коммерческий уровень, доступный нахаляву.
V>Там только на ЗП 800 человекам по самым скромным подсчётам требуется 6-8 лямов $$ ежемесячно.
Для системы такого масштаба — неудивительно.

V>>>Этот проект был создан не для зарабатывания, а для вытеснения зарабатывающих.
V>·>Т.е. github под конец весь разорился и все умерли. Happy end.
V>350 лямов денег подарили...
Как же... подарили... Инвестировали.