SVN удалить головную боль, что я делаю не так?

Question

Я полностью сбит с толку, если я нахожусь в рабочей копии и делаю следующее:

svn mkdir trunk 
svn mkdir tags 
svn mkdir branches 
svn commit -m "added trunk branches and trunk" 
cd trunk 
touch a b c d e f g 
svn add a b c d e f g 
cd .. 
svn commit -m "added files"
svn copy trunk tags/1.0 
svn commit -m "tagged 1.0"

Теперь я хочу удалить файл и отметить другую версию

 svn delete trunk/e
 svn commit -m "deleted file e"
 svn copy trunk tags/1.1
 svn commit -m "created tag 1.1"

Я получаю сообщение об ошибке, подобное следующему:

/ СВН / репо / банан /! СВН / WRK / 1f39512a-0e1e-11e0-9d1f-5be991158436 / 63885 / теги / 1,1 / е» путь не найден

Какого черта я здесь делаю неправильно?

Обновление:

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

Answer 1

Это, очевидно, известная проблема с Subversion при работе с удалениями после коммитов.Когда вы фиксируете, ваша рабочая копия становится смешанной версией рабочей копией, которая затем не допускает фиксацию удалений.

Вы можете проверить это, запустив svnversion перед выполнением обновлений /совершает.Вы заметите, что смешанная ревизия помечена версией рабочей копии, например, «0: 4».

Из документа Subversion о лучших практиках :

Каталоги и файлы вашей рабочей копии могут иметь разные «рабочие» ревизии: это преднамеренная функция, которая позволяет смешивать и сопоставлять старые версии вещей с более новыми.Но есть несколько фактов, о которых вы должны знать:

1. После каждой фиксации SVN ваша рабочая копия имеет смешанные ревизии.Вещи, которые вы только что зафиксировали, теперь находятся в ревизии HEAD, а все остальное - в более старой ревизии.
2. Некоторые коммиты запрещены:
   • Вы не можете зафиксировать удаление файла или каталога, который нерабочая версия HEAD отсутствует.
   • Вы не можете зафиксировать изменение свойства в каталоге, в котором нет рабочей версии HEAD.
3. svn update будетПриведите всю свою рабочую копию к одной рабочей ревизии, и это типичное решение проблем, упомянутых в пункте №2.

Справочник по книге : Ограничение смешанных ревизий.

Это также хорошо объясняется в этой статье о рабочих копиях смешанной ревизии .

Answer 2

Сообщение об ошибке также включало это

svn: Commit failed (details follow): 
svn: File '1.1/e' is out of date

Я обнаружил, что если я делаю svn-обновление перед копированием в теги, это работает

svn delete trunk/e   
svn commit -m "deleted file e"   
svn update 
svn copy trunk tags/1.1   
svn commit -m "created tag 1.1"

И это прекрасно работает. Объяснение этого поведения приветствуется.