В настоящее время у нас есть репозиторий Subversion со следующей структурой:
Я считаю, что это довольно плохая раскладка, но в настоящий момент сложно ее полностью изменить.
Лично мне не нравится subversion, в основном из-за того, что проверка истории занимает много времени, а также из-за того, что ветвление и слияние являются громоздкими и т. Д., Поэтому я действительно хочу использовать вместо этого git.
К сожалению, мы не можем просто переключиться на git, так как умственные способности некоторых могут быть чрезмерными, поэтому я изучал git-svn, чтобы узнать, могу ли я практически использовать это для решения проблемы.
К сожалению, это напрямую приводит к плохой ситуации, поскольку я хочу разбить каждый проект на один репозиторий git, и я не хочу воссоздавать проверку git-svn на каждом компьютере, на котором я работаю. поэтому я, хотя, возможно, есть возможность создать какой-то прозрачный прокси / шлюз git ← → svn, чтобы нажатие на это репо «фиксировалось» на репо svn, а фиксация на репо svn обновляла репозиторий git.
Google не был моим другом, нашел только общую помощь по использованию git-svn, поэтому я спрашиваю вас, есть ли у вас какие-нибудь хорошие идеи для этого.
Для прозрачного шлюза Git / Svn вы можете использовать SubGit, он очень хорошо соответствует вашим требованиям, за исключением того, что прямо сейчас он поддерживает только простые однопроектные (/ trunk, / branch, / tags) или многопроектные (/ project / trunk, ...) макеты.
Если вы не контролируете или не хотите связываться с сервером Subversion, вы не можете использовать SubGit. В этом случае вы могли бы создать автоматически синхронизируемый репозиторий git для каждого транка. Наша команда работает таким образом - у нас есть мост git-Subversion, который синхронизирует изменения между репозиторием git нашей команды и стволом проекта в корпоративном репозитории Subversion, так что использование git прозрачно для других пользователей Subversion.
Подробнее о настройке см. https://github.com/mrts/git-svn-bridge.
Эту установку мы используем в производстве более года.
Я предполагаю, что самая большая проблема настройки заключается в том, что ветки git будут объединены в один коммит во время слияния с стволом. Для нас это не проблема - мы используем кратковременные ветки задач и считаем их легковесными, эфемерными «единицами работы», которые могут переходить в основную ветку одним блоком, а история ветвей сохраняется в git.
В основном у вас есть два варианта:
Разрешите git-svn на стороне клиента решить проблему. Ваша первоначальная проверка займет некоторое время, но она может предоставить вам все те же функции, что и собственная проверка svn (включая нажатие и извлечение git svn dcommit
и git svn [fetch|rebase]
), и если вы клонируете его с помощью --stdlayout
, вы получаете полную поддержку ветвления и тегирования. (Я делаю это в своей компании - я один из двух сотрудников, которые используют git с svn-сервером, и у меня нет никаких проблем.)
Клонируйте репозиторий с помощью git-svn на другой сервер (или даже тот же сервер), а затем просто начните размещать git из этого репозитория. Затем у вас есть собственный репозиторий git со всеми данными svn из прошлого.
Если вы не хотите «git svn clone» на каждом компьютере, вы можете: