Mail.RuПочтаМой МирОдноклассникиИгрыЗнакомстваНовостиПоискВсе проекты

Программное обеспечение
с открытым исходным кодом

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

На этом ресурсе собрана информация об открытых
разработках Mail.Ru Group и ее сотрудников.

Git as Subversion

Git as Subversion — это реализация Subversion-сервера (по протоколу svn) для Git-репозиториев.

Он позволяет работать с Git-репозиторием, используя консольный Subversion-клиент, TortoiseSVN, SvnKit и подобный инструментарий.

Какова цель проекта?

Проект создан для того, чтобы позволить работать с одним и тем же репозиторием как в Git-стиле, так и в Subversion-стиле.

Git-стиль

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

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

К сожалению, этот подход не работает в случае, когда изменяемые документы не поддерживают слияние (например, это характерно для двоичных файлов).

Subversion-стиль

Использование централизованной системы контроля версий более удобно в случае использования документов не поддерживающих слияние (например, это характерно для двоичных файлов) за счет наличия механизма блокировок и более простого и короткого цикла публикации изменений.

Необходимость совместить Git-стиль и Subversion-стиль работы с одним репозиторием возникает из-за того, что разные сотрудники в рамках одного проекта работают с принципиально разными данными. Если утрировать, то программисты предпочитают Git, а художники любят Subversion.

Как оно работает?

Где хранятся Subversion-данные репозитория?

Для представления Subversion репозитория нужно хранить информацию о том, какой номер Subversion-ревизии соответствует какому Git-коммиту. Вычислять эту информацию каждый раз при запуске нельзя, так как тогда первый же git push --force нарушит порядок ревизий. Эти данные лежат в ветках refs/git-as-svn/*. В частности из-за этого не требуется отдельного резервного копирования для Subversion-данных.

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

Например:

  • номер ревизии с предыдущим изменением файла;
  • данные о том, откуда был скопирован файл;
  • MD5-хэш файла.

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

Данные о блокировках файлов в данный момент также хранятся в файла кэша.

Как работает коммит?

Одна из самых важных деталей системы — сохранение изменений.

В общих чертах, алгоритм следующий:

  1. В момент команды svn commit клиент отправляет на сервер свои изменения. Сервер запоминает их. В этот же момент происходит первая проверка клиентских данных на актуальность.
  2. Сервер берет голову ветки и начинает формировать новый коммит на базе полученных от клиента данных. В этот момент происходит ещё одна проверка на актуальность клиентских данных.
  3. Проверяется целостность svn properties для заливаемых данных.
  4. Сервер пытается консольным Git-клиентом сделать push нового коммита в текущую ветку этого же репозитория. Далее по результату push-а:
    • если все хорошо — загружаем последние изменения из git-коммитов и радуемся;
    • если не fast forward — загружаем последние изменения из git-коммитов и идём к шагу 2;
    • если отбили хуки — сообщаем клиенту;
    • если другая ошибка — сообщаем клиенту.

Таким образом, за счёт использования в данной операции консольного Git-а, мы избегает гонки с заливкой напрямую через Git и получаем хуки в качестве приятного бонуса.

Отличие от других решений

Проблему совмещения Git и Subversion стиля работы с системой контроля версий можно решить разными способами.

Поддержка Subversion у GitHub

Это, наверное, самый близкий аналог.

Основная проблема данной реализации — неотделимость от GitHub. Также, внезапно, данная реализация не поддерживает Git LFS.

В случае с GitHub также не понятно, где хранится соответствие между Subversion-ревизиями и Git-коммитами. Это может быть проблемой при восстановлении репозиториев после внештатных ситуаций.

SubGit

Сайт: http://www.subgit.com/

Достаточно интересная реализация при которой поддерживаются Git и Subversion-репозитории в синхронном состоянии. За счет чего обеспечивается синхронность репозиториев — непонятно.

Subversion репозиторий и git svn

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

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

Функционал

Данная реализация позволяет большинству Subversion-пользователей работать, не задумываясь о том, что они на самом деле используют Git-репозиторий.

Что уже есть?

  • Работают, как минимум, следующие клиенты:
    • Консольный Subversion-клиент;
    • TortoiseSVN;
    • SvnKit.
  • Работают, как минимум, следующие операции:
    • svn checkout, update, switch, diff
    • svn commit
    • svn copy, move (Операции поддерживаются, но данные об источнике копирования не сохраняются. Информация об источнике копирования вычисляется на основании изменений Git-репозитория.)
    • svn cat, ls
    • svn lock, unlock
    • svn replay (svnsync)
  • Поддерживается Git LFS;
  • Поддерживаются git submodules (Данные из git submodule видны в репозитории в режиме только для чтения);
  • Авторизация через LDAP;
  • Интеграция с GitLab.

Чего еще нет?

  • Большие пробелы в документации;
  • Из Subversion доступна только одна ветка.

Технические ограничения

  • Нельзя средствами Subversion менять svn properties;
  • Нельзя создавать пустые директории.

Ссылки