Могут различные клоны мерзавца-svn того же репозитория SVN ожидать мочь совместно использовать изменения затем мерзавец svn dcommit?
Я читал, много из "идет от svn до мерзавца" и других "статей" рабочего процесса мерзавца-svn о сети, и тем не менее я думаю, что они часто справляются с чрезмерно простыми ситуациями. Они часто предназначаются для парней, которые просто хотят использовать мерзавца и взлом локально, не используя полную мощность мерзавца, как получение по запросу, выборка, слияние и т.п. между несколькими разработчиками, которые все клонировали бы репозиторий SVN с мерзавцем-svn, затем все еще, ожидает мочь продвинуть их изменения любое время к (официальному) репозиторию SVN и возвратиться к работе в мерзавце и совместному использованию их материала и т.д.
Каждый раз, когда эти статьи признают, что Вы не можете сделать всего, что Вы сделали бы в чистом мерзавце, последствия и возможные взлеты винта ясно никогда не объясняются (или возможно это - просто я?). Даже страница справочника мерзавца-svn упоминает протесты, но не действительно обширным способом.
На основе того, что я считал, я чувствую, что могли быть проблемы, когда мерзавец-svn используется в том особенном методе, который я опишу ниже. Кто-то может сказать мне, если я прав относительно этого?
Вот "требуемый" способ сделать вещи:
- У нас есть проект в репозитории SVN
- Разработчик git-svn-clone svn repo. Он начинает взламывать вещи локально
- Git-svn-clone разработчика B тот же svn repo. Он начинает взламывать вещи самостоятельно.
- После выполнения этого в течение некоторого времени, возможно добавления devs C/D/... и наличия других разработчиков, которые, "стандарт" svn соглашается на исходный repo, пользователи мерзавца хотели бы совместно использовать свой код и сделать все виды волшебства мерзавца.
- Кто-либо из тех пользователей мерзавца хотел бы смочь продвинуть теперь объединенные изменения в svn (dcommit?)
Мой вопрос: я мечтаю? Я читал некоторое время назад, в книге мерзавца я думаю, это, git-svn-clone мог создать репозитории мерзавца, которые являются, конечно, "зеркалом" svn repo, но тот мерзавец repos создал тот путь различными разработчиками, будет иметь различные "идентификаторы", и фиксации имели бы различные хеши. Таким образом, мое понимание было то, что те, которые мерзавец repos не совместно использует общего предка мерзавца и таким образом не смог бы использовать всего мерзавца, управляют, чтобы Вы совместно использовали, объединиться и так далее. Действительно ли это верно, мы собираемся столкнуться с проблемами с этим рабочим процессом?
Иногда я читал, это могло быть сделано, по крайней мере, с помощью "официального" пустого репозитория мерзавца, который будет единственным, чтобы быть git-svn-cloned, и все пользователи мерзавца должны были бы запустить, формируют этого. Затем Вам нужен кто-то, кто отвечает за этого центрального мерзавца repo и собирает изменения между мерзавцем devs, прежде dcommiting все к svn repo. Это было бы единственным способом для пользователей мерзавца не знать, что исходный мерзавец repo происходит из svn и позволил бы им использовать все команды мерзавца, как им нравится. Единственный человек, который должен был бы бегло говорить и на мерзавце и на svn (и знать о протестах мерзавца-svn) будет "менеджер по слиянию" (или независимо от того, что его звонят).
Я полностью неправильно понимаю протесты мерзавца-svn? Есть ли какой-либо более простой способ сделать это?
5 ответов
Проблема, конечно же, в шаге 4 . Команда dcommit пытается воспроизвести вашу локальную историю на сервере. Dcommit делает вид, что вы клиент SVN. Теперь, если код, который вы фиксируете, принадлежит не только вам, это сложно передать в SVN.
Вот что пишет по этому поводу гуру :
- Для простоты и взаимодействия с SVN, это рекомендовал всем пользователям git-svn clone, fetch и dcommit прямо из сервер SVN (удаленный SVN репозиторий) и избегайте всех git-clone / pull / merge / push операции между репозиториями git и ветками которые либо получаются через git svn clone и которые также используются для вернуть ревизии в удаленный SVN репозиторий.
- Рекомендуемый метод обмена кодом между ветвями git а пользователи - это git format-patch и git am, или просто git svn dcommit в SVN репозиторий.
- Так как git svn dcommit использует git svn rebase внутри, любые ветки git мы git push to перед git svn dcommit on им потребуется принудительная перезапись существующей ссылки на пульте репозиторий. Это вообще считается плохой практикой, см. Подробную информацию можно найти в документации по git-push.
- Запускать git merge или git pull не рекомендуется в ветке, которую мы планируем git svn dcommit из. SVN не представляют слияние в любых разумных или полезная мода, чтобы пользователи, использующие SVN не может видеть никаких слияний, которые мы сделали. Кроме того, если мы git merge или git извлечь из ветки git, которая является зеркало ветки SVN, git svn dcommit может совершить неправильный ветвь.
- git clone не клонирует ветки в ссылках / пультах / иерархии или любые метаданные git-svn или config. Так репозитории, созданные и управляемые с помощью при использовании git-svn следует использовать rsync для клонирования, если клонирование должно быть выполнено
- Мы не должны использовать параметр --amend команды git commit при изменении, которое мы уже совершили. это считается плохой практикой - исправлять коммиты, которые мы уже отправили в удаленный репозиторий для других пользователей и dcommit с SVN аналогичен этому. Более подробную информацию об этом можно найти при изменении одного коммита и Проблемы с перезаписью истории .
Раньше я создавал начальный клон git svn, а затем делился им .git среди разработчиков с помощью git, поэтому у нас были точно такие же ссылки.
Похоже, это сработало. правильно, поскольку мы могли использовать «определенные функции git» между пользователями git, пока мы оставались в линейном дереве (т.е. перебазирование вместо слияния).
Как только вы перейдете к «распределенной» проблеме, вам будет лучше с одним голым репозиторием git, клонированным среди разработчиков.
Что касается фазы экспорта-импорта в общедоступное репозиторий SVN, для других целей, сценарии
git2svn и svn2git могут помочь инкапсулировать волшебство.
Другие соображения при работе в репозиториях Git и SVN можно найти в вопрос «Рабочий процесс и справка по git, 2 проектам svn и одна« рабочая копия »»
Я нашел эту запись в блоге, в которой предлагается держать отдельную ветку для синхронизации с репозиторием Subversion, так что по-прежнему можно будет выполнять push/pull в главной ветке.
В последнее время я много экспериментировал с этим и думаю, что мне удалось придумать установку, которая отчасти работает. Да, это строгий режим только для перебазирования, да, это сложно, но вы можете использовать Git для локальной работы (скорость, история, тайник, индекс и т. Д.).
Я думаю, вы можете использовать ветки за кулисами, когда вы сотрудничаете с другими пользователями Git в вашей команде, но лично я не слишком много экспериментировал с этим. Пока вы линеаризуете журнал перед фиксацией, он должен работать.
Вот краткая версия (во многом повторяет то, что уже было сказано):
- Клонировать репозиторий Subversion в «извлекающее» репо на центральном сервере
- Инициировать «голое» репо на том же сервере
- Перемещение из репозитория fecthing в чистое репо
- Попросите разработчиков клонировать чистое репо, а затем
git svn init svnurlдля настройки удаленного git-svn иgit update-ref refs / remotes / git-svn refs / remotes / origin / master, чтобы у git-svn был указатель в ревизию
- Автоматически (обработчик фиксации) имеет "выборку" репозитория svn rebase и отправку в чистое репо
- Разработчики извлекают из чистого репо с помощью
git pull --rebase - Разработчики, работающие
git svn dcommitсначала необходимо повторитьupdate-refвыше в случае новых ревизий, поступающих из SVN.
На этой странице есть иллюстрация рабочего процесса (мне нужно больше очков репутации, прежде чем я смогу встроить изображение). Обновление: Начнем:
