Subversion: рабочая копия-старая версия разработки

Я разрабатываю OSX, и одна из моих рабочих копий Subversion только что начала возвращать следующую ошибку для всех команд, однако мои другие проверки работают нормально. Я получаю одно и то же сообщение как с моими установленными SVN-файлами, так и с моим клиентом Cornerstone, но другие рабочие каталоги в порядке.

> svn update
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: Working copy '/working_directory' is an old development version (format 12); to upgrade it, use a format 18 client, then use 'tools/dev/wc-ng/bump-to-19.py', then use the current client
> svn upgrade
svn: E155019: Can't upgrade '/working_directory' as it is not a pre-1.7 working copy directory
svn: E150000: Missing default entry

у меня нет bump-to-19.py скрипт в любом месте на моем компьютере (по данным find / -type f -name bump-to-19.py), однако я думаю, что смог найти его на Apache хранилище. Тем не менее, я не знаком с тем, что он делает, или как его использовать. В идеале я могу избежать проверки новой версии этого рабочего каталога и ручного слияния во всех моих (многих) изменениях.

единственная информация, которую я смог найти, связана с в NetBeans и javahl и я тоже.

редактировать: после загрузки bump-to-19.py файл и сделать его исполняемым, я попробовал его против моего рабочего каталога, чтобы нет avail:

> ./bump-to-19.py working_directory/
error: format is 29 not 18: 'working_directory/'
8
cornerstone macos svn

4 ответов

хотя я не смог понять, почему мой рабочий каталог был поврежден, я смог обойти его, используя rsync - есть вариант, C, который будет игнорировать файлы и каталоги CVS/SVN при создании резервной копии. Я сделал резервную копию с помощью этой опции, снова проверил проект, а затем скопировал резервную копию обратно в новый рабочий каталог. SVN снова счастлив.

> rsync -arC working_directory working_directory_no_svn
> rm -rf working_directory
> svn co https://svn.example.com/project/trunk working_directory
> rsync -ar working_directory_no_svn working_directory
12

У меня была такая же проблема и вот как я решил:

  1. удалить .папка svn на верхнем уровне (rm-rf .svn)
  2. проверка программного обеспечения снова от SVN (svn co ...)
  3. хорошо идти!
8

Я знаю, что это было вокруг некоторое время, но я нашел решение, используя подсказки, данные в SVN... В основном используйте команду upgrade, как она гласит. Используя CMD, я пошел в папку рабочей области, где находился проблемный проект. Вызовем проект Project1. Вы вызываете команду:

"svn upgrade project1"

это решило мою проблему надлежащим образом, не вовлекая какой-то Хак или обходной путь.

5

У меня была аналогичная проблема, мой svn-версия 1.7.10, однако мой плагин Subversion для Eclipse немного старше, я предполагаю 1.6.что-то.

использование команды "rsync-arC working_directory archive_no_svn" было прорывом - по крайней мере, теперь у меня была копия часов синхронизации, которые я только что завершил.

Я попытался использовать "svn co", но это была неправильная версия, поэтому я просто запустил обновление с помощью плагина Subversion в Eclipse - это восстановило рабочий каталог из репозитория-в значительной степени то, что мне было нужно, и это была правильная версия.

получение rsync обратно в правильное место было трюком. rsync, кажется, отбрасывает рабочую папку в расположение архива, создавая archive_location/working_directory / the-files. Таким образом, синхронизация архивированных данных обратно в working_directory была достигнута с помощью: rsync-ar archive_no_svn/working_directory .

теперь я должен узнать об обновлении моей Subversion плагин для Eclipse до 1,7

0