Могут ли разные клоны git -svn одного и того же репозитория svn ожидать, что они смогут делиться изменениями, а затем git svn dcommit?

Я прочитал много статей "перейдите от svn до git" и других статей "git -svn workflow" в Интернете, и все же я думаю, что они часто имеют дело с чрезмерно простыми ситуациями. Они часто нацелены на парней, которые просто хотят использовать git и взломать локально, не используя полную мощность git, например, pull, fetch, merge и т.п. между несколькими разработчиками, которые все бы клонировали репозиторий svn с помощью git -svn, то все равно ожидайте, что сможете в любое время внести изменения в (официальный) svn-репозиторий и вернуться к работе в git и поделиться своим материалом и т.д.

Всякий раз, когда эти статьи признают, что вы не можете делать все, что вы сделали бы в чистом git, последствия и возможные зависания никогда не будут четко разъяснены (или, может быть, это только я?). Даже страница git -svn man упоминает оговорки, но не очень широко.

На основании того, что я прочитал, я чувствую, что могут возникнуть проблемы, когда git -svn используется таким образом, о чем я расскажу ниже. Может ли кто-нибудь сказать мне, если я прав по этому поводу?

Вот "желаемый" способ делать вещи:

У нас есть проект в репозитории svn
Разработчик A git -svn-клонировать svn repo. Он начинает рушить вещи локально.
Разработчик B git -svn-клонировать то же самое svn repo. Он сам начинает разбирать вещи.
После этого в течение некоторого времени, возможно, добавив devs C/D/... и имея других разработчиков, которые выполняют "стандартные" svn, фиксирует исходное репо, пользователи git хотели бы поделиться своим кодом и сделать все виды магии git.
Любой из этих пользователей git хотел бы использовать текущие объединенные изменения для svn (dcommit?)

Мой вопрос: я мечтаю? Я читал некоторое время назад, в книге git, я думаю, что git -svn-clone может создавать репозитории git, которые, конечно, являются "зеркалом" репозитория svn, но этот git repos создал у разных разработчиков будут разные "идентификаторы", и у коммитов будут разные хэши. Поэтому я понял, что эти репозитории git не будут иметь общего предка git и, следовательно, не смогут использовать все команды git, которые вам нужно разделить, объединить и т.д. Это правда, мы столкнемся с проблемами с этим документооборотом?

Иногда я читал, что это можно сделать, используя хотя бы "официальный" годовой репозиторий git, который был бы единственным, кто был бы git -svn-клонирован, и всем пользователям git приходилось начинать сформируйте это. Тогда вам нужен кто-то, кто отвечает за это центральное репо git, и собирает изменения между git devs, прежде чем dcommiting все в svn repo. Это было бы единственным способом для пользователей git "не знать", что исходный репозиторий git поступает из svn и позволяет им использовать все команды git по своему усмотрению. Единственный человек, который должен был бы свободно говорить как git, так и svn (и знать о git -svn оговорках), будет "менеджером слияния" (или тем, что он назвал).

Я полностью недопонимаю git -svn оговорки? Есть ли более простой способ сделать это?

Ответ 1

Конечно, проблема - это шаг 4. Dcommit пытается воспроизвести вашу локальную историю на сервере. Dcommit притворяется, что вы SVN-клиент. Теперь, если код, который вы делаете, не только от вас, это то, что трудно выполнить для SVN.

Вот что пишет гуру:

Для простоты и взаимодействия с SVN, это рекомендуется, чтобы все пользователи git -svn клон, выборка и dcommit непосредственно из сервер SVN (удаленный SVN репозиторий, который есть) и избегать всех Операции git -clone/pull/merge/push между хранилищами и ветвями gitкоторые либо извлекаются через git svn клонов и которые также используются для назад изменения в удаленный SVN хранилище.

Рекомендуемый способ обмена кодом между ветвями gitи пользователи git format-patch и gitam или просто git svn dcommit для SVN хранилище.

Поскольку git svn dcommit использует git svn rebase внутри, любые ветки git, мы git нажмите до git svn dcommit on им потребуется принудительная перезапись существующего ref на дистанционном репозиторий. Это обычно считается плохой практикой, см. git -push документации для деталей.

Выполнение git merge или git pull не рекомендуется в ветке, которую мы планируем git svn dcommit from. SVN не представляют собой слияния в любых разумных или полезная мода, поэтому пользователи, использующие SVN не вижу никаких слияний, которые мы сделали. Кроме того, если we git слить или gitвытащите из ветки git, которая является зеркало ветки SVN, git svn dcommit может совершить неправильное филиал.

git Клон не клонирует ветки в рамках refs/remotes/hierarchy или любые метаданные git -svn или config. Так репозитории, созданные и управляемые с помощью используя git -svn следует использовать rsyncдля клонирования, если клонирование должно быть выполнено на всех.

Мы не должны использовать параметр -amend для git commit при изменении we уже пропустили. это считается неправильной практикой --amend что мы уже подтолкнули к удаленный репозиторий для других пользователей и dcommit с SVN аналогичен этому. Более подробную информацию об этом можно найти при изменении одной фиксации и Проблемы с историей переписывания.

Ответ 2

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

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

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

Клонировать репозиторий Subversion в "выборку" репо на центральном сервере.
Инициировать "голый" репо на том же сервере
Нажмите от репозитория fectping до открытого репо
Если разработчики клонируют голый репо, а затем
1. git svn init svnurl для настройки пульта git -svn и
2. git update-ref refs/remotes/git-svn refs/remotes/origin/master, поэтому git -svn имеет указатель на версию

Автоматически (фиксация крюка) имеет "выборку" rebo svn rebase и нажмите на голый репо Разработчики выходят из голого репо с помощью git pull --rebase Разработчики, работающие под управлением git svn dcommit, сначала должны повторить update-ref выше в случае новых версий, поступающих из SVN.

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

Ответ 3

То, что я использовал, - это создать начальный git svn-клон, а затем поделиться им с разработчиками, используя git, поэтому мы имели точно такие же ссылки.

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

Ответ 4

Как только вы войдете в "распределенную" проблему, вам будет лучше с одним открытым git репо, клонированным среди разработчиков.
Что касается этапа экспорта-импорта для публичного репо SVN, для других использовать сценарии
git2svn и svn2git могут помочь инкапсулировать магию.

Другие соображения при работе в git и SVN-репозиториях находятся в вопросе "Рабочий процесс и помощь с git, 2 проектами svn и одной" workcopy ""

Ответ 5

Я нашел этот пост в блоге, в котором предлагается сохранить отдельную ветку для синхронизации с репозиторием Subversion, чтобы можно было сделать нажмите/вытащите ведущую ветвь.

Ответ 6

Есть инструмент, который решает проблему совместного использования репозитория Git, синхронизированного с репозиторием Subversion.

SubGit является двунаправленным серверным зеркалом Git -SVN.

Можно установить SubGit в репозиторий Subversion и получить репозиторий Git, автоматически синхронизированный с SVN:

$ subgit configure $SVN_REPOS
# Adjust $SVN_REPOS/conf/subgit.conf to specify branches, tags and other options;
# Adjust $SVN_REPOS/conf/authors.txt to specify git & svn authors mapping
$ subgit install $SVN_REPOS
...
$ INSTALLATION SUCCESSFUL

SubGit устанавливает привязки pre-commit и post-commit в репозиторий Subversion, pre-receive и post-receive hooks в репозиторий Git. В результате он немедленно переводит входящие изменения с SVN и Git сторон. После установки SubGit разработчики могут использовать любой клиент Git для клонирования и работы с репозиторием Git.

SubGit не полагается на Git -svn, он использует свой собственный механизм перевода, разработанный нашей командой. Более подробно об этом вы можете узнать в сравнении с SubGit и Git -svn. Общая документация по SubGit доступна здесь.

Версия 1.0 SubGit требует локального доступа к репозиторию Subversion, то есть SVN и Git репозитории должны находиться на одном хосте. Но с версией 2.0 мы собираемся ввести режим прокси-сервера Git, когда репозитории Subversion и Git могут быть расположены где угодно и только в хранилищах Git есть SubGit, установленный в них, то есть хранилища Subversion остаются нетронутыми.

SubGit - это коммерческий продукт. Это бесплатно для open-source, академического проекта, а также для проектов с до 10 коммиттерами.

Отказ от ответственности: я один из разработчиков SubGit.

Ответ 7

Одна из проблем, которые я воспринимаю с помощью git -svn, заключается в том, что она хранит git -svn-id в комментарии фиксации; потому что это переписывает это commit, оно меняет его SHA1, поэтому вы не можете проталкивать его в любом месте, где люди будут делиться им.

Я действительно предпочитаю bzr-svn, потому что вместо этого он сохраняет bzr revid в удаленной ревизии SVN, используя функцию свойств ревизии SVN, а это означает, что локальная ревизия не переписывается. Он также обладает желаемым свойством, что два независимых вытягивания одной ветки SVN приведут к идентичным и совместимым ветвям bzr.