Subversion: Как вы исправляете рабочую копию после цикла загрузки дампа ->

Question

Несколько недель назад наш подвальный узел freemium отправил нам сообщение о том, что мы превысили наш размер. После нескольких попыток исправить это (и понимая, что невозможно сжать репозиторий без цикла загрузки дампа -> и обрезать вещи), мы решили, что пришло время перейти на новый хост с более мягкими ограничениями размера (и перенести git в то же время.)

Однако в то же время мы были заблокированы для доступа «только для чтения», что было неудачно, потому что были некоторые важные местные изменения, которые не были проверены. Поэтому я решил принять решительные меры и сократить старые версии серверов с помощью метода загрузки дампа -> нагрузки, чтобы мы снова и снова работали, чтобы мы могли работать с нашими локальными модификациями. Я фактически сбросил все, кроме последней версии (r525), после создания локальной резервной копии всего.

Это все работало - после длительного процесса с участием помощи хозяина, я успешно dumped-> перезагружается наш репозиторий, и это при пересмотре 1.

Однако теперь наши клиенты отказываются обновить нашу существующую работу копии, потому что они думают, что они работают копию ревизии 525:

svn: A reported revision is higher than the current repository HEAD revision.

Таким образом, вопрос: можно ли «исправить» моя рабочая копию думать, что это при пересмотре 1?

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

Answer 1

Ваша самая безопасная ставка - это, вероятно, создание патча (или нескольких патчей - если мы говорим об изменениях в нескольких рабочих копиях) с изменениями - это можно сделать «в автономном режиме», не связываясь с репозиторием. Затем проверьте новую рабочую копию и примените к ней патча.

Вы создаете патч с svn diff > patch.diff и применяете его с помощью svn patch.

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

Answer 2

Удалить скрытые файлы .svn из конфликтующих папок и обновить до HEAD. Он будет поддерживать локальные изменения.

Answer 3

С новыми версиями Subversion вы можете использовать sqlite для изменения базы данных рабочей копии, это довольно опасно, и вы можете полностью сломать вещи. Если вы хотите дать ему попробовать, вот как это сделать.

Сначала выяснить, что последняя редакция находится в удаленном хранилище находится по адресу:

$ svn info https://example.com/svn/project/trunk/ 
Path: trunk 
URL: https://example.com/svn/project/trunk 
Repository Root: https://example.com/svn 
Repository UUID: fdecad78-55fc-0310-b1b2-d7d25cf747c9 
Revision: 86002 <-- This is the value you want 
Node Kind: directory 
Last Changed Author: user@example.com 
Last Changed Rev: 49367 
Last Changed Date: 2008-05-23 17:01:34 +0100 (Fri, 23 May 2008) 

затем редактировать БД SQLite и изменить пересмотр быть последним видел в хранилище:

cd .svn 
$ sqlite3 wc.db 
SQLite version 3.7.13 2012-07-17 17:46:21 
Enter ".help" for instructions 
Enter SQL statements terminated with a ";" 
sqlite> update nodes set revision = 86002 where revision > 86002; 
sqlite> .exit 
$ cd .. 
$ svn up 
Updating '.': 
At revision 86002. 

Возможно, вам также понадобится запустить этот SQL, если последние коммиты были сделаны в вашем проекте:

update nodes set changed_revision = 86002 where changed_revision > 86002;