не может согласиться на svn, потому что рабочая копия всегда устарела
Ожидайте.... сделал Вас, когда-либо используют Дистанционную работу.NET, вызывают, это - реальная вещь ее замена. Дистанционная работа.NET является довольно сложной сама. Я нахожу WCF легче и лучше размеченный.
3 ответа
Попробуйте создать новую проверку, затем скопируйте в него свои изменения. У меня тоже были некоторые необъяснимые проблемы с TortoiseSVN, и это единственное, что помогло.
Вот распространенный сценарий, который, как я видел, вызывает у многих людей головную боль. Возможно, вы находитесь в таком состоянии:
- Рабочая копия сломана. SVN жалуется, что файл 'bar' под 'foo' каталог вызывает проблемы.
- Разработчик делает резервную копию foo каталог.
- Разработчик удаляет каталог foo из рабочей копии.
- Разработчик выполняет svn update, foo и bar возвращаются, и svn доволен.
- Разработчик копирует резервную копию foo обратно в рабочую копию, и svn больше не может обновлять и / или фиксировать
Фатальная ошибка здесь была, когда разработчик сделал резервную копию каталога 'foo', они также сделали резервную копию всех скрытые каталоги ".svn", вложенные в foo.
Итак, решение (по моему опыту) состоит в том, чтобы использовать возможность черепахи svn "export" сделать резервную копию foo. Экспорт Tortoise svn создаст копию структуры каталогов без каких-либо метаданных svn (dirs .svn). Таким образом, когда вы вернетесь к шагу 3 и svn будет доволен, когда вы скопируете резервную копию обратно в каталог рабочей копии, svn сможет правильно зафиксировать изменения.
Опять же, если вы создаете резервную копию только одного файла, это не поможет.
Если вы можете обновить файл, рабочая копия, похоже, работает правильно.
Вы обновляли каталог или только файл? У меня были ситуации, когда svn не мог зафиксировать, потому что свойства каталога изменились в репозитории. Обновление каталога решило эту проблему.
Еще одна попытка - использовать svn cleanup .
Новая проверка - последнее средство.