Как разработчик SVNKit, я бы посоветовал вам взглянуть на реализацию SVN сервера на основе нашего DAV сервлета.
Например, разработчики GitHub не скрывали, что посматривают в наши исходники, когда работают над поддержкой SVN на GitHub.
А как разработчик SubGit, я недоумеваю, почему наш продукт стрёмный. SubGit в первую очередь решает задачу постепенной миграции с Subversion на Git, в этом его основное отличие от git as svn; при этом:
— SubGit абсолютно прозрачен для пользователей Git и для пользователей Subversion — поддерживаются все функции обеих систем, то есть наличие SubGit неочевидно для пользователя;
— SubGit'у достаточно обычного удалённого доступа к Subversion репозиторию, чтобы создать Git зеркало этого репозитория;
— Такие компании как Comcast, CBS, Boeing, SpaceX, Cisco, etc. не считают SubGit стрёмным. Наоборот, они его используют в production успешно и не один год.
— Некоторые задачи синхнронизации потребовали нетривиальных решений, и это было одной из самых интересных частей нашего проекта. Это и надёжная репликация, и трансляция информации о merge и поддержка eol-style свойств. Думаю многие из решений заслуживают отдельных постов;
— И да, SubGit — это коммерческий продукт, к которому мы предоставляем не менее коммерческий саппорт, при этом SubGit бесплатен для небольших команд, academic и open source проектов.
Можете попробовать SubGit, это такая альтернатива git-svn. Работает на сервере, автоматически синхронизирует SVN и Git репозитории с помощью hook'ов, которые вызываются на каждый commit и push. Поскольку синхронизация происходит на сервере, то пользователи могут использовать любой SVN или Git клиент.
Сразу скажу, что SubGit — это коммерческий продукт, и я один из его разработчиков. Если интересно, могу написать отдельный пост по этой теме.
Например, разработчики GitHub не скрывали, что посматривают в наши исходники, когда работают над поддержкой SVN на GitHub.
А как разработчик SubGit, я недоумеваю, почему наш продукт стрёмный. SubGit в первую очередь решает задачу постепенной миграции с Subversion на Git, в этом его основное отличие от git as svn; при этом:
— SubGit абсолютно прозрачен для пользователей Git и для пользователей Subversion — поддерживаются все функции обеих систем, то есть наличие SubGit неочевидно для пользователя;
— SubGit'у достаточно обычного удалённого доступа к Subversion репозиторию, чтобы создать Git зеркало этого репозитория;
— Такие компании как Comcast, CBS, Boeing, SpaceX, Cisco, etc. не считают SubGit стрёмным. Наоборот, они его используют в production успешно и не один год.
— Некоторые задачи синхнронизации потребовали нетривиальных решений, и это было одной из самых интересных частей нашего проекта. Это и надёжная репликация, и трансляция информации о merge и поддержка eol-style свойств. Думаю многие из решений заслуживают отдельных постов;
— И да, SubGit — это коммерческий продукт, к которому мы предоставляем не менее коммерческий саппорт, при этом SubGit бесплатен для небольших команд, academic и open source проектов.
Сразу скажу, что SubGit — это коммерческий продукт, и я один из его разработчиков. Если интересно, могу написать отдельный пост по этой теме.