Работа в синхронизации с SVN вверх по течению

Ответ 1

Документация git svn рекомендует следующий рабочий процесс при работе с ветвями Subversion:

# Clone a repo (like git clone):
git svn clone http://svn.example.com/project -T trunk -b branches -t tags

# Append svn:ignore settings to the default git exclude file:
git svn show-ignore >> .git/info/exclude

# View all branches and tags you have cloned:
git branch -r

# Create a new branch in SVN
git svn branch waldo

# Reset your master to waldo:
git reset --hard remotes/waldo

# local changes
git add ...
git commit ...

# pull changes on current branch
git svn rebase

# send changes to Subversion
git svn dcommit

# check for new branches
git svn fetch

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

Чтобы отследить ветку waldo репозитория Subversion, начните с

git checkout -b waldo-svn remotes/waldo

Суффикс -svn должен избегать предупреждений формы

warning: refname 'waldo' is ambiguous.

а также напомнить, что это ветвь git предназначена для отслеживания ветки Subversion. Всегда сохраняйте изменения в этих ветвях линейными!

Чтобы обновить waldo-svn, запустите

git svn rebase

Это приведет к изменениям из Subversion и переустановит любые локальные изменения поверх них. Он также достаточно умен, чтобы распознать, когда одно из ваших локальных изменений было принято дословно: он будет заменен на транзакцию Subversion и будет иметь строку, начинающуюся с git-svn-id: ... в сообщении фиксации.

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

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

git diff waldo-svn waldo-fix-frobnicator

Затем, когда вы git svn rebase, чтобы догнать репо Subversion, вам нужно будет просмотреть журнал и принять решение о соответствующих расположениях ваших ветвей выпуска, вроде GTD для git.

Ответ 2

Я не уверен, что понял вашу проблему, но я думаю, что вы можете искать git stash.

Ответ 3

Я не уверен, насколько высоко связаны ваши функции с восходящим кодом, но вы можете разделить "ядро" восходящего потока, которое вы поддерживаете отдельно от своих дополнений. Это действительно действительно работает, если вы можете разбить базу кода.

Ответ 4

Вы действительно не дали понять, что хотите. В отношении вашего заявления о том, что "(поддерживая отдельную ветвь для каждой функции, поэтому нетривиально)", я могу только удивляться, почему вы думаете, что это должно быть тривиально. Два патча, которые взаимно зависимы друг от друга, должны либо быть одним патчем, либо, по крайней мере, на одной ветки. Патч B, который зависит от A (но не наоборот), должен быть либо на ветке с A, либо на ветке с родительским фиксатором на ветке A.

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

Хорошо, теперь это легче решить.

У вас две проблемы.

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

Сделайте ветку вилки. Как только вы поймете, что функция не вернется, вытащите ее из ветки, удерживающей функцию вилки. Затем git revert функция fork применит патч, который отменяет функцию из local- *. Повторите при необходимости.

(2) Разве вы беспокоитесь о том, что происходит с патчем вверх по течению.

Вам действительно не нужно отслеживать, применили ли вы свой патч к удаленной стабильной (отныне r-стабильной). Вы не потеряете патч в L-stable, если вы выберете r-stable и они еще не применили патч. Единственная возможная проблема заключается в том, что будут конфликты слияния на коде из патча, но вы не сможете обойти это. Как только они применили патч, он будет выглядеть точно так же, как вы разрешили конфликты слияния (в этом случае вы не получите никакого отличия от того, когда вы вытащите патч из R-stable), или они будут сливаться по-другому, и вы получите конфликт слияния, и им будет предоставлена ​​возможность принять решение сохранить свой путь или ваш путь. Просто помните, что если вы хотите сохранить свой путь, вы будете разветвляться от r-stable. Один из вариантов - переместить "свой путь" на вилку и продолжать свой путь на локальном - *.