Странная проблема с Subversion - "Файл уже существует" при попытке воссоздать каталог, который использовался в моем репозитории

Ответ 1

Мне удалось обойти это, вернувшись к последней версии, в которой был каталог mysql, а затем удалил содержимое каталога, поместил в него новое содержимое и снова проверил новую информацию. Любопытно, есть ли у кого-то лучшее объяснение того, что там происходит.

Ответ 2

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

После некоторого разочаровывающего беспорядка, я обнаружил, что мне нужно:
(с использованием TortoiseSVN в Windows)

• Переместите конфликтующие папки из рабочей копии (чтобы я не потерял свою незавершенную работу)
• Сделайте svn update, который добавил старые файлы/папки в рабочую копию
• svn delete папка
• commit
• Скопируйте новую папку обратно в рабочую копию (чтобы вы удалили все папки .svn внутри)
• commit

К сожалению, он (A) требует двух коммитов, и (B) теряет историю изменений файла, поскольку он только отслеживает повторное добавление (если кто-то не может объяснить, как это исправить). Альтернативное решение, которое работает с этими двумя проблемами, - это пропустить шаги 3 и 4, единственная проблема заключается в том, что старые/ненужные файлы все еще могут присутствовать в вашем каталоге. Вы можете удалить их вручную.

Хотелось бы услышать какие-либо дополнительные сведения, которые могут быть у других, которые могут быть на этом.

Саймон.

[Обновить] В порядке, у меня была такая же проблема снова, но папка с нарушением была НЕ в последнем коммите, поэтому update не восстановил ее. Вместо этого мне пришлось просматривать репозиторий и delete папку-нарушитель. Я мог бы add вернуть папку и commit успешно.

Ответ 3

Была аналогичная проблема. Чтобы решить эту проблему, обновляется из svn trunk с опцией приоритета локальных файлов.

svn update path/ --accept=mine-full

После того, как вы могли совершить как обычно. Конечно, будьте осторожны с этим.

Ответ 4

уже был этот тип проблем.

Мое решение было:

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

#!/bin/bash

find -name '.svn' | while read directory;
do
    echo $directory;
    rm -rf "$directory";
done;

удалить локальный репозиторий и переустановить весь проект. не знаю, достаточны ли частичное удаление/проверка.

рассматривает

Ответ 5

Это неприятная... таинственная ошибка и ясное исправление.

update/revert/commit не работает в моей ситуации. Я не сделал ничего странного - только некоторые svn двигаются.

Для меня DID:

svn remove offender
svn commit
cd ..
rm -fR parent
svn up parent
cd parent
svn remove offender again
svn commit
copy offender back in (minus .svn dirs)
svn add
svn commit

Как ни странно. В принципе, svn remove --force offender по какой-то причине не полностью удалялся. Что это за сообщение об ошибке. Только удалив родителя, а затем обновив родителя, это стало очевидным, потому что преступник снова появился! svn удалил нарушителя, а затем правильно удалил его.

Ответ 6

Я не уверен, что это поможет вам, но я думаю, что когда вы сделаете svn add mysql после того, как вы его удалите, он просто восстановит каталог (так что не делайте mkdir самостоятельно). Если вы создаете каталог, то svn ожидает в нем директорию .svn, потому что он уже "знает" об этом.

Ответ 7

• переименуйте новый путь к temp
• вернуть новый путь (не temp!), поэтому svn не пытается его совершить.
• выполнить оставшиеся изменения.
• скопируйте путь внутри репозитория: svn copy -m "скопированный путь" -r
• обновите свою рабочую копию.
• mv все файлы из temp в новый путь, который исходит из обновления
• фиксировать локальные изменения с момента пересмотра
• Хороший день, включая историю; -)

Ответ 8

У меня была эта проблема в проекте, который я запускаю на Netbeans. Я просто щелкнул правой кнопкой мыши по файлу и обновил его, чтобы исправить его (после SVN).

Ответ 9

Это решение сливается гладко и не теряет историю:

• Переместить/обработать копию/нарушителя во временное место.
• Сделайте svn checkout svn + ssh://svn.example.com/repo/offender to/working-copy/offender.
• Вручную перемещайте файлы из временного местоположения в новую версию.
• Удалить временное местоположение.

Ответ 10

Эта ситуация возникла, если в репозитории есть объект, который создается текущей транзакцией.

Простой сценарий:

• дважды проверяйте один каталог, так как DIR1 и DIR2
• make 'svn mkdir test' в
• сделать фиксацию из DIR1
• попытайтесь сделать commit DIR2 (без svn up), SVN вернет эту ошибку.

То же самое при добавлении одинаковых файлов из двух рабочих копий.

Ответ 11

В соответствии с решением Atmocreation, за исключением того, что вам не нужно повторно проверять весь проект, что полезно, если у вас уже есть работа.

Скажем, у вас есть рабочая копия:

/foo/

который содержит каталоги:

/foo/bar/baz

и вы получите сообщение об ошибке при фиксации:

svn: File already exists: filesystem '/foo/bar'

Резервное копирование содержимого панели где-нибудь:

mkdir -p ~/tmp/code_backup
cp -r /foo/bar ~/tmp/code_backup

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

find ~/tmp/code_backup/bar -name .svn -type d -exec rm -rf {} \;

Дважды проверьте, что копия идентична:

diff -r -x .svn dist ~/tmp/code_backup/dist

Удалите из рабочей копии повреждающий каталог:   cd/foo   rm -rf bar

И затем восстановите его из репозитория:

cd /foo
svn update bar

Скопируйте измененные файлы из резервной копии:

cp -r ~/tmp/code_backup/bar /foo/

Теперь вы можете совершить ошибку без ошибок.

Ответ 12

Я столкнулся с этой проблемой сегодня, когда Xcode разбился во время слияния ветвей. Как-то файл был загружен в репозиторий svn, но он не был записан в svn db должным образом. Я выполнил следующие команды в каталоге, где файл существовал локально:

svn revert bad.file
svn del svn://my.svnserver.com/svnDB/path/to/the/offending/file/bad.file

Затем я снова добавил файл из своей локальной системы:

svn add bad.file
svn commit -m "Re adding bad.file"

Успех!

Ответ 13

Вам нужна команда svn 'export'. С этим вы можете поместить файл или полное дерево каталогов в состояние другой ревизии в другой ветке.

Так что-то вроде

rm file #without 'svn' in front!
svn export myrepo/path/to/[email protected]<revision> .
svn commit

Ответ 14

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

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