Это бы работало, если бы интеграции работали только через вызов бинарника git. На самом деле они часто ходят напрямую в файлы внутри .git Либо через libgit2, либо вообще полностью самостоятельно.
Да, смотрели. И да, это действительно очень похоже на то, что мы делаем. Но там до сих пор есть прекрасное https://github.com/facebookexperimental/eden/issues/7#issuecomment-473357543
Есть байка, что они выложили это в open source случайно и поэтому эти патчи невозможно собрать и использовать за пределами фейсбука.
С автором этой статьи трудно не согласиться в том, что большая кодовая база потребует отдельной довольно сложной инфраструктуры вроде поиска по коду и продвинутой системы сборки. Это верно хоть для моно, хоть для поли-репозитория. На мой взгляд такой инструментарий для монорепозитория делать несколько проще за счет наличия единственного и окончательного источника правды о состоянии кода в данной ревизии и централизованной истории всех изменений.
Виртуализация файловой системы в VCS, как в нашей и других подобных системах, позволяет закрыть многие проблемы на которые указывает автор, вроде невозможности иметь доступ разом ко всему коду. Да, разработка таких штук не очень простая, а компании, которые приходят к необходимости их создания решают в первую очередь свои проблемы и не очень спешат делиться этими разработками. Но и репозиториев, для которых не хватало бы просто производительности git в мире пока не очень много. А если их будет становиться больше, то появится и давление к созданию общедоступных средств для работы с ними.
А вот по части невозможности глобальных рефакторингов, автор имхо просто ошибается. В нашем репозитории я вполне проделывал вещи вроде grep | xargs | sed, разве что вместо простого grep там был вызов серверного code search, а все остальное естественным образом быстро работало в нашей vcs и загружало только затронутые файлы. Невозможность сделать ревью таких изменений до возникновения конфликтов мне тоже кажется надуманной.
Мы тестировали работу гита на отдельных фрагментах репозитория и результаты нас не радовали. Для доклада мне хотелось получить какие-то числа для всего репозитория, чтобы было проще сравнить разные vcs.
У нас нет оснований предполагать, что от конвертации всего репозитория git магическим образом начнет работать лучше. Там будут те же принципиальные проблемы, что и с mercurial — многие операции требуют обхода всего дерева каталогов и их трудоемкость растет с размером репозитория. Те цифры производительности, которые мне удалось на скорую руку получить, эти предположения подтверждают.
В целом вы правы, мы планируем поддерживать высокоуровневые команды git по степени востребованности нашими пользователями. Но, например, пользователи переходящие с svn сильно удивляются количеству действий, которые надо сделать для отправки небольшого изменения на ревью: arc checkout -b + arc add + arc commit + arc push + arc pr create — это 5 действий вместо одного привычного им svn commit. Поэтому мы движемся в сторону создания интерфейса более высокого уровня, который упрощал бы типичные сценарии. Это в чем-то похоже на подход git-flow с поправкой на то, что у нас trunk based модель.
Что касается arc log, то тут действительно мы сильно отошли от гита. Информацию о копированиях мы храним прямо в графе объектов, поэтому нет необходимости какими-то эвристиками извлекать её из данных. Операция вычисления лога для пути — серверная, поэтому нет проблем с доступом ко всему графу коммитов. В аккуратном представлении он легко влезает в память и его обходы получаются очень быстрыми. Для определения влияющих на путь коммитов мы отдельно поддерживаем индекс файлов, затронутых каждым коммитом. Он тоже оказывается не безумно большим. В результате на клиенте достаточно загрузить только коммиты попавшие в лог.
VFS for Git — действительно очень интересный проект с похожими на наши целями и средствами. В Microsoft пошли несколько иным путем и добавляют виртуализацию ФС и ленивую загрузку объектов прямо в git за счет фигурного вырезания фильтров для sparse checkout и ignore файлов. Мы пробовали применить похожий подход в mercurial и довольно быстро поняли, что либо придется переписать почти всю vcs, либо мириться с кучей пограничных случаев, когда безобидная операция (тот же git log) начинает выкачивать все содержимое репозитория локально.
Когда наш проект начинался еще одним недостатком GVFS было отсутствие поддержки linux, что для нас было критичным. Но с тех пор экспериментальная поддержка появилась.
Это бы работало, если бы интеграции работали только через вызов бинарника git. На самом деле они часто ходят напрямую в файлы внутри .git Либо через libgit2, либо вообще полностью самостоятельно.
Да, смотрели. И да, это действительно очень похоже на то, что мы делаем. Но там до сих пор есть прекрасное https://github.com/facebookexperimental/eden/issues/7#issuecomment-473357543
Есть байка, что они выложили это в open source случайно и поэтому эти патчи невозможно собрать и использовать за пределами фейсбука.
С автором этой статьи трудно не согласиться в том, что большая кодовая база потребует отдельной довольно сложной инфраструктуры вроде поиска по коду и продвинутой системы сборки. Это верно хоть для моно, хоть для поли-репозитория. На мой взгляд такой инструментарий для монорепозитория делать несколько проще за счет наличия единственного и окончательного источника правды о состоянии кода в данной ревизии и централизованной истории всех изменений.
Виртуализация файловой системы в VCS, как в нашей и других подобных системах, позволяет закрыть многие проблемы на которые указывает автор, вроде невозможности иметь доступ разом ко всему коду. Да, разработка таких штук не очень простая, а компании, которые приходят к необходимости их создания решают в первую очередь свои проблемы и не очень спешат делиться этими разработками. Но и репозиториев, для которых не хватало бы просто производительности git в мире пока не очень много. А если их будет становиться больше, то появится и давление к созданию общедоступных средств для работы с ними.
А вот по части невозможности глобальных рефакторингов, автор имхо просто ошибается. В нашем репозитории я вполне проделывал вещи вроде
grep | xargs | sed, разве что вместо простого grep там был вызов серверного code search, а все остальное естественным образом быстро работало в нашей vcs и загружало только затронутые файлы. Невозможность сделать ревью таких изменений до возникновения конфликтов мне тоже кажется надуманной.Мы тестировали работу гита на отдельных фрагментах репозитория и результаты нас не радовали. Для доклада мне хотелось получить какие-то числа для всего репозитория, чтобы было проще сравнить разные vcs.
У нас нет оснований предполагать, что от конвертации всего репозитория git магическим образом начнет работать лучше. Там будут те же принципиальные проблемы, что и с mercurial — многие операции требуют обхода всего дерева каталогов и их трудоемкость растет с размером репозитория. Те цифры производительности, которые мне удалось на скорую руку получить, эти предположения подтверждают.
В целом вы правы, мы планируем поддерживать высокоуровневые команды git по степени востребованности нашими пользователями. Но, например, пользователи переходящие с svn сильно удивляются количеству действий, которые надо сделать для отправки небольшого изменения на ревью:
arc checkout -b+arc add+arc commit+arc push+arc pr create— это 5 действий вместо одного привычного имsvn commit. Поэтому мы движемся в сторону создания интерфейса более высокого уровня, который упрощал бы типичные сценарии. Это в чем-то похоже на подход git-flow с поправкой на то, что у нас trunk based модель.Что касается arc log, то тут действительно мы сильно отошли от гита. Информацию о копированиях мы храним прямо в графе объектов, поэтому нет необходимости какими-то эвристиками извлекать её из данных. Операция вычисления лога для пути — серверная, поэтому нет проблем с доступом ко всему графу коммитов. В аккуратном представлении он легко влезает в память и его обходы получаются очень быстрыми. Для определения влияющих на путь коммитов мы отдельно поддерживаем индекс файлов, затронутых каждым коммитом. Он тоже оказывается не безумно большим. В результате на клиенте достаточно загрузить только коммиты попавшие в лог.
Когда наш проект начинался еще одним недостатком GVFS было отсутствие поддержки linux, что для нас было критичным. Но с тех пор экспериментальная поддержка появилась.