Возможно, вы захотите прочитать из SVN documentation about the FS_FS backend.. Но в основном файл db/current в вашем репо представляет собой текстовый файл с последним номером ревизии, тогда как db/revs/- это папка, содержащая файл для каждой ревизии (который после 1.5 может быть разбит в папках осколков).
Если ваш инструмент резервного копирования распадается на revs/и создает резервные копии всех файлов там, и пользователь делает фиксацию во время резервного копирования, возможно, вы пропустите это последнее коммит, прежде чем файл rev будет перемещен из db/транзакции/в db/revs/НО еще сохраняйте файл db/current, который был увеличен. То есть, у вас есть revs/для 51 ревизии, но текущие списки «52» - как последняя фиксация!
Рекомендуемый способ обеспечения согласованной резервной копии - игнорировать db/транзакции (так как это пространство для царапин используется при построении rev) и резервное копирование db/current ДО того, как вы создаете резервную копию db/revs. Худший случай здесь - revs/может содержать, например, 52 пересмотра и текущий момент до 51. Это согласовано, и все будет работать нормально. «Восстановление svnadmin» даже исправит это для вас.
ОДНАКО, если вы не делаете резервное копирование db/current сначала (как вы этого не сделали), очень просто открыть его с помощью vim, nano или другого текстового редактора и просто уменьшить число. В вашем случае измените 52 на 51, и все должно правильно проверить.
Часть о резервных копиях также описаны в документе comparing FS_FS to FS_Base that I found с момента, когда FS_FS впервые был введен
Можете ли вы 'svnadmin dump'? –
Да, он сбрасывает все, кроме последней ревизии. Думаю, это помогает, спасибо! –
как вы делаете резервные копии? похоже, что может быть проблема, когда ревизия только наполовину поддерживается? – vinnyjames