4 Гб это смешной размер. Он даже много меньше моей рабочей копии.
Лично у меня, git-репозиторий раздувался до ~250Гб (получен через git svn, рабочая копия ~30Гб). Git его вполне нормально переваривал. Mercurial, к слову, развалился на гораздо меньших объемах.
Но нужно отметить, что 32-х битная сборка git-а не может с ним ничего сделать.
Для того, чтобы Perforce попал в список рассматриваемых вариантов, кто-то должен был его предложить и объяснить, почему он лучше. Таких людей не оказалось.
Беглый взгляд на Perfoce не выявил никаких преимуществ. К тому же очень настораживает тот факт, что данные о рабочей копии лежат на сервере. То есть для нормальной работы требуется подключение к серверу, причем быстрое.
Использовать всем Subversion.
Разработчки могут использовать git svn или аналоги, но он не дает возможности работать вдвоём над одной фиче-веткой. Плюс боль и страдание с ветками стабильных версий
Использовать всем Git.
Не вышло. Производительность падает, а недовольство растёт.
Использовать SubGit.
Есть опасение, что мастер-мастер связка репозиториев развалится в самый неподходящий момент.
Переезд на GitHub.
Не подходит, т.к. репозиторий должен быть внутри компании.
Распилить на два репозитория.
Нужны дополнительные телодвижения для того, чтобы поддерживать соответствие между ними. Особенно тяжело будет при работе со стабильными ветками для боевого кода.
Написать git-as-svn.
Нужно время на разработку и поддержку.
Все варианты — дрянь. Приходилось выбирать меньшее зло.
Основная проблема: «Git не даёт никаких преимуществ и создаёт дополнительные проблемы, если файлы не поддаются мержу» свойственна всем распределенным системам контроля версий, в том числе и Mercurial-у.
Если данные нельзя мержить, то Git лишь добавит им проблем без какой-либо выгоды.
Хуже того: же они будут лишены механизма блокировок, который ранее снижал вероятность получения конфликтов.
Основную боль в Subversion вызывает то, что нельзя сохранить в системе контроля версий какой-либо промежуточный результат крупных изменений (к примеру: я поменял 100500 файлов, починил компиляцию, но не починил тесты) без разламывания общей версии.
Так же при обновлении нельзя откатиться до состояния «до обновления», т.к. надо разрешить все конфликты любой ценой — обратной дороги нет.
Теоретически это должно решаться ветками, но в Subversion это крайне неудобный механизм.
У Git нет официального консольного клиента для 64-х битной платформы.
Мне известен только один свежий 64-х битный клиент: github.com/slonopotamus/wingit/releases
Так как Git использует паки через отображение файла на память, использование 32-х битной сборки накладывает серьезное ограничение на размер репозитория.
У Git нет официального консольного клиента для 64-х битной платформы.
Мне известен только один свежий 64-х битный клиент: github.com/slonopotamus/wingit/releases
Так как Git использует паки через отображение файла на память, использование 32-х битной сборки накладывает серьезное ограничение на размер репозитория.
Там безумные объемы и нет таких жестких требований к соответствию данных и кода.
Разработка по остаточному принципу. Задействовано два человека.
Мы не знаем, на них ответов и это нас останавливает.
Но, справедливости ради, пока мы тыкали в него палочкой, он вел себя стабильно.
Есть не официальная сборка: github.com/slonopotamus/wingit
Но, такова жизнь: пока не появится в команде хоть кто-то, кто с ним работал ранее, вероятность его использования минимальна.
Буду очень признателен, если предоставите хоть какой-то внятный обзор на тему «почему Perforce — хорошо».
Лично у меня, git-репозиторий раздувался до ~250Гб (получен через git svn, рабочая копия ~30Гб). Git его вполне нормально переваривал. Mercurial, к слову, развалился на гораздо меньших объемах.
Но нужно отметить, что 32-х битная сборка git-а не может с ним ничего сделать.
В конечном счете, git-as-svn крутится на машине с gitlab-ом и все счастливы.
Беглый взгляд на Perfoce не выявил никаких преимуществ. К тому же очень настораживает тот факт, что данные о рабочей копии лежат на сервере. То есть для нормальной работы требуется подключение к серверу, причем быстрое.
Это боль, страдание и унижение.
Мы рассматривали варианты:
Разработчки могут использовать git svn или аналоги, но он не дает возможности работать вдвоём над одной фиче-веткой. Плюс боль и страдание с ветками стабильных версий
Не вышло. Производительность падает, а недовольство растёт.
Есть опасение, что мастер-мастер связка репозиториев развалится в самый неподходящий момент.
Не подходит, т.к. репозиторий должен быть внутри компании.
Дорого.
Нужны дополнительные телодвижения для того, чтобы поддерживать соответствие между ними. Особенно тяжело будет при работе со стабильными ветками для боевого кода.
Нужно время на разработку и поддержку.
Все варианты — дрянь. Приходилось выбирать меньшее зло.
В Git и Subversion разный workflow. И нашей целью было совместить оба варианта.
pcottle.github.io/learnGitBranching/
Хуже того: же они будут лишены механизма блокировок, который ранее снижал вероятность получения конфликтов.
Так же при обновлении нельзя откатиться до состояния «до обновления», т.к. надо разрешить все конфликты любой ценой — обратной дороги нет.
Теоретически это должно решаться ветками, но в Subversion это крайне неудобный механизм.
Данные и код сильно взаимосвязаны. Из-за этого желательно держать их в одном репозитории.
Пример из жизни:
Мне известен только один свежий 64-х битный клиент: github.com/slonopotamus/wingit/releases
Так как Git использует паки через отображение файла на память, использование 32-х битной сборки накладывает серьезное ограничение на размер репозитория.
Мне известен только один свежий 64-х битный клиент: github.com/slonopotamus/wingit/releases
Так как Git использует паки через отображение файла на память, использование 32-х битной сборки накладывает серьезное ограничение на размер репозитория.