Subversion Слияние нескольких рабочих копий?

Мы полностью потеряли наш репозиторий, и у нас есть 8 разработчиков с незавершенными изменениями. Предполагается, что восстановление из резервной копии невозможно.

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

Короче, можно ли без сервера объединить две разные рабочие копии?

изменить: пожалуйста, не смей меня из-за того, что у меня нет резервных копий; эта часть вне моего контроля. Предполагалось, что их подкрепляют каждую ночь.

Последующие действия: вот что мы сделали:

  1. Начал с самой актуальной рабочей копии всех разработчиков.
  2. Импортировал это в новое репо.
  3. Работаем от последней редакции рабочей копии к самой старой, копируем ТОЛЬКО файлы с зафиксированными изменениями.
  4. мыть-полоскание-повторить 6 раз. (2 разработчика не оставили незавершенных изменений).
  5. экспортировал все старые рабочие копии, заархивировал их и при необходимости хранил для безопасного хранения.
  6. Обновили наши версии в базе данных управления выпусками до очень молодого репо.

backup recovery svn
person hometoast    schedule 20.01.2009    source источник
comment
Столкнувшись с необходимостью объединить усилия нескольких разработчиков, я использовал Git. Git очень хорош в создании и объединении веток. git-svn работает неплохо. По сути, вы помечаете код, с которого начали, в SVN. Создайте репозиторий git на основе этого тега с помощью git-svn. Скопируйте измененные файлы. Проверьте разницу. Зафиксируйте изменения. Затем обновите SVN до последней версии (которая объединит изменения SVN с локальными изменениями). Затем верните свои изменения в SVN. Одно репозиторий git можно использовать для выполнения нескольких слияний и подталкиваний. Иаков   -  person TheJacobTaylor    schedule 16.02.2010

Ответы (7)


arrow_upward
4
arrow_downward

Поскольку вы потеряли свой репозиторий (извините за это), вы также потеряли всю историю.

Все, что вы можете сделать сейчас, это начать с нуля.

  1. создать новый репозиторий
  2. создать структуру папок
  3. экспортировать рабочую копию первого пользователя в новую папку
  4. импортировать экспортированную папку в репозиторий
  5. все остальные пользователи теперь проверяют новую рабочую копию
  6. все остальные пользователи теперь «экспортируют» свою исходную рабочую копию поверх новой рабочей копии

Под «экспортом» я подразумеваю создание копии рабочей копии, но без скрытых папок .svn в ней.

person Stefan    schedule 20.01.2009
comment
Спасибо, что это звучит достаточно просто. Не весело, но и не сложно;) - person hometoast; 21.01.2009

arrow_upward
1
arrow_downward

Привет, хитрая проблема. Но это то, что я бы сделал.

  1. Создайте новый репозиторий.
  2. Создайте 8 веток и 1 ствол
  3. Import the developers work on the branches.
    • Developer 1 on branch 1
    • Разработчик 2 на ветке 2
    • и т. д. и т. д.
  4. Затем начните слияние от ветви 1 к стволу. И когда у вас стабильное состояние в магистрали, вы продолжаете ветку 2 и т. Д. И т. Д.

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

/ Йохан

person Johan    schedule 20.01.2009

arrow_upward
0
arrow_downward

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

PS: плохо, что у вас нет резервных копий ...

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

person Keltia    schedule 20.01.2009
comment
Я упростил свой вопрос. также добавлено примечание о резервных копиях. : D - person hometoast; 20.01.2009
comment
Понял. Моя точка зрения все равно остается в силе, как для вашей собственной резервной копии такой важной вещи, так и для DVCS :) - person Keltia; 20.01.2009

arrow_upward
0
arrow_downward

Самый простой способ - создать свой собственный сервер, создать тестовое репо, добавить в него одну (наиболее стабильную) сборку и объединить рабочие копии по одной. Но да, вы потеряли всю историю, потому что потеряли свое старое репо.

Затем вы можете создать свое основное репо из этого тестового.

person omermuhammed    schedule 20.01.2009

arrow_upward
0
arrow_downward

Я бы попытался просто выбрать одну рабочую копию, чтобы выполнить импорт для нового репо, а затем перенаправить оставшиеся 7 рабочих копий в этом новом репо с помощью переключателя svn, возможно, с перемещением, чтобы они поверили, что это то же репо, но перемещено. Просто попробуйте выбрать рабочую копию для первоначального импорта, в которой нет (или как можно меньше) структурных изменений из потерянного репозитория: например, просто файл редактирует.

Конечно, сделайте тонны резервных копий своих рабочих копий на случай, если вышеперечисленное не сработает :)

person nezroy    schedule 20.01.2009
comment
Это было то, что я думал, что мне нужно сделать. Не знаю, как WC справится с более высокими оборотами, чем у головы. И да, я уже сделал две копии своего собственного туалета. - person hometoast; 20.01.2009
comment
Возможно, вы сможете использовать svnadmin dump / load для изменения номера ревизии после первоначального импорта. Не уверен, насколько это просто, я никогда не работал с форматом файла дампа из дампа svnadmin. - person nezroy; 20.01.2009
comment
Рабочие копии никогда не следует переключать / взламывать / редактировать, чтобы они указывали на репозиторий с другой историей, чем исходный репозиторий .. так как это невозможно со стратегией обновления подверсий (отправка только различий с базовой версией, которая известна обеим сторонам). - person Bert Huijben; 21.01.2009

arrow_upward
0
arrow_downward

Subversion сохраняет исходную версию файла в локальной рабочей копии. Создайте новый репозиторий, сделайте копию самой старой рабочей копии, отмените изменения в КОПИИ рабочей копии, затем импортируйте эту рабочую копию в свой новый репозиторий.

svn import: http://svnbook.red-bean.com/en/1.0/re12.html

После того, как вы импортировали, вы можете использовать svn switch --relocate, чтобы перенаправить другие рабочие копии в ваш новый репозиторий и зафиксировать изменения.

переключатель svn --relocate: http://svnbook.red-bean.com/en/1.1/ch04s05.html

person Joseph Anderson    schedule 20.01.2009
comment
переключатель --relocate, вероятно, не сработает, потому что номера ревизий и т. д. не будут совпадать ... - person sth; 20.01.2009
comment
переключатель --relocate следует использовать только в том случае, если репозиторий переместился .. НЕ, если вы изменили историю .. (uuid в рабочей копии используется для предотвращения этого; и чтобы убедиться, что вы не потеряете работу, если попытаетесь в любом случае) - person Bert Huijben; 21.01.2009

arrow_upward
0
arrow_downward

Создайте новый репозиторий в том же месте, что и старый, из самой исходной рабочей копии (таким образом вы уловите больше истории в новом репозитории).

Если и где это не сработает, поместите в .svn-каталоги из проверки нового репозитория. (Например, оформить заказ и удалить все, кроме .svn-каталогов)

person Olav    schedule 15.02.2010