2016-05-06 1 views
0

Я сейчас перехожу из cvs в git. (Скорчите, если хотите, но только если ваша компания существует уже 15 лет.)слияние разреженного тега с веткой при переходе с cvs на git

У меня есть старые старые теги CVS, которые только помечают некоторые файлы в репо, не все из них. Когда я проверяю эти теги, это похоже на репо, в котором все непомеченные удалены. Это хорошо известная разница в модели ветвления между cvs/svn, с одной стороны, и git - с другой.

Я хотел бы, чтобы новая отрасль, как это:

  • начать с моей основной ветвью и сделать новую ветвь релиза.
  • заменить только файлы с тегами tags/A.
  • затем вместо этого замените только файлы с тегами tags/B.
  • затем зафиксировать всю сумму.

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

Есть ли хороший способ сделать это?

+0

Мне никогда не приходилось это делать, в частности, но я начал с того, что увидит, что с ними делает cvs2 * (начиная с cvs2git). Если все остальное не удается, просто сделайте это вручную: конвертируйте большую часть репозитория с помощью cvs2git, затем создайте некоторые специальные элементы и используйте фильтр-ветвь и/или трансплантат/замену, чтобы вставить их. Это практично, только если у вас есть небольшой набор из них, иначе вам может понадобиться автоматизировать это тоже. – torek

ответ

1

Можете ли вы сделать это после факта, теперь в CVS, чтобы подготовить репозиторий cvs для скрипта cvs2git? Пройдите все теги и добавьте недостающие файлы в тег. cvs tag самостоятельно, без -F не будет перемещать тег. Таким образом, вы можете повторно применить тег/A, основанный на теге/B, и будет применять его только к файлам, которые еще не помечены, что именно вы хотите.

Возможно, у вас слишком много тегов, чтобы сделать это практичным. Я думаю, что 20 000 тегов x 5 минут/тег = 34 дня.

Но я не знаю, было бы намного быстрее сделать это в git. И как только вы попадете в git, вам придется очистить все артефакты cvs2git: фиксация фиксации и т. Д., Связанная с каждым тегом. Но я мог представить, теоретически, через каждый тег, проверяя больше файлов, добавляя их, исправляя фиксацию (с автором и датой, сохраненной через соответствующие переменные среды GIT_), перемещая тег, сравнивая его с предыдущим фиксатором, на самом деле на ветке, если вы можете просто переместить тег назад.

Кроме того, важно ли вам, чтобы ваши теги находились на названной ветке, на которой они должны быть включены? Потому что со всеми этими фиксациями фиксации они не будут, даже с вашими исправлениями. Это может быть прагматично, чтобы ваша ветка master была преобразована самым элегантным и содержательным способом, позволяя некоторым из старых ветвей быть немного твердой.

Update

Просто сумасшедший мысли. Будет ли смысл делать cvs2svn, исправить теги, а затем svn2git? Я знаю, что это звучит безумно, но subversion имеет изменения в git, но способность работать с файловыми файлами, такими как cvs, поэтому это может быть лучшее место для исправления тегов.

1
git checkout -b release master 
git merge --no-commit -s ours tags/A tags/B 
git checkout tags/A -- . 
git checkout tags/B -- . 

git commit # put the above sequence in the commit message if you have love in your heart 

Первая команда - «проверить текущий хозяин, но как новую ветвь с именем release:».

Второй вариант «настроен, но не фиксирует объединение no-op из тегов/A и тегов/B».Перед фиксацией вы можете организовать любой результат слияния, который вы хотите.

... в частности, третья и четвертая команды загружают версии того, что находится в этих двух коммитах.

+0

Возможно, если он захочет исправить «теги/A», тогда проверка git в рецепте может быть «git checkout -b fixA tags/A ~'. Новый коммит будет создан поверх того же самого родителя, что и 'tags/A'. Тогда 'tags/A' можно перенести в' fixA' (или даже 'fixA ~', если окажется, что они идентичны). (И снова, для фиксации вы захотите установить различные переменные среды GIT_AUTHOR и т. Д., Чтобы дать ей тот же самый автор/коммиттер/даты, что и теги/A). – Mort

Смежные вопросы