Восстановить соединение проекта Subversion Eclipse

Ответ 1

Если вы используете сублипсу в качестве поставщика SVN, я рекомендую сделать следующее

Team → Share project обычно достаточно для соединения метаданных.

(то есть, считая, что файлы .svn все еще существуют, что они, кажется, есть, если вы можете работать в командной строке).

Надеюсь, что это поможет, почему это произойдет, я понятия не имею

Ответ 2

Я нашел простой способ только reimport проекта

Ответ 3

Просто команда Team → Share (за ответ на этот вопрос, предоставленный @Paul Whelan) не работает для меня. Мастер Share Project действовал так, как будто проект еще не был в SVN (даже если в моем проекте была папка .svn).

Я решил решить эту проблему, удалив дополнения Subversive и JavaHL (с помощью кнопки Help | About Eclipse | Installation Details | закладка Установленное программное обеспечение | Uninstall...), а затем переустановите Subversive. При появлении запроса после перезапуска Eclipse я решил установить соединитель SVNKit, а не соединитель JavaHL.

После этого, когда я снова попробовал Team → Share Project..., Eclipse правильно распознал, что мой проект уже присутствовал в SVN, и он успешно восстановил соединение.

Ответ 4

Приложение: выясняется, что моя проблема проявляется, когда я запускаю Eclipse вне компании vpn, с проектом в рабочей области, который привязан к репозиторию svn внутри vpn. К счастью, переключение плагинов Eclipse svn с подрывной подзаймы действительно разрешило его.

Ян

Ответ 5

Из затмения я закрыл проект и снова открыл, что разрешило проблему. Все ссылки SVN возвращаются для всех проектов в моей рабочей области.

Ответ 6

У меня была такая же проблема, и этот форум помог мне найти правильный ответ.

Мой предыдущий проект был настроен с использованием подзаголовка. Новое затмение имело subvesive.

Установка подзаголовка помогла мне вернуть параметры svn в команде!

Надеюсь, что это поможет кому-то другому.

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

Аньшу Пратеек

Ответ 7

Не зная, на какой платформе вы работаете, я не знаю, похожа ли ваша проблема на мою. Тем не менее, я недавно (фактически на двух разных платформах!) Имел проблемы, когда обновление Subversive (или, возможно, самого Eclipse, непонятное) приводило к тому, что разъемы больше не загружались. Без соединителей Subversive не может подключиться к проекту. Но Eclipse не собирается блокировать вас от вашего проекта, так как он просто удалит связанные с SVN функции.

Посмотрите на представление "Ошибки", которое представляет собой журнал различных ошибок Eclipse (исключения, не найденные в классе и т.д.), и посмотрите, есть ли какие-либо строки, относящиеся к компонентам Subversive. К сожалению, я не могу рекомендовать решение - на моей платформе Mac OSX этого было достаточно, чтобы переустановить базовые элементы и разъемы Subversive. На моей машине Linux (возможно, из-за обновления ОС) мне нужно полностью переустановить Eclipse, так как для меня было достаточно большого количества трещин, чтобы иметь возможность полностью исследовать ее.

Ответ 8

В выпуске Juno с Subversive я сделал:

• Файл/Импорт вызывает всплывающее окно Импорт.
• Оттуда выберите Общие/Существующие Проекты в Рабочую область.
• На следующей панели вы выбираете корневой каталог. Затем он покажет вам все подкаталоги. Все они будут выбраны по умолчанию.
• Отмените выбор тех, которые вы не хотите.

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

Ответ 9

То же самое в моем случае:.svn dirs были там, но мой проект не поддерживал действия svn.

После немного выкалывания оказалось, что подрывный плагин просто исчез после принудительного закрытия затмения.

Решение заключалось в (re) установке подрывной функции, и теперь все хорошо.

Приветствия v.

UPDATE: я переключил eclipse на новую версию, у которой просто не был установлен плагин, поэтому я должен был установить его с нуля.

Ответ 10

Это сработало для меня: щелкните правой кнопкой мыши- > TortoiseSVN → Настройки → Значок Наложение свойств, Выбор Shell как кэш состояния. Нажмите "ОК", "Обновить страницу".

Ответ 11

Я могу достоверно воспроизвести эту проблему - это происходит при проверке определенных проектов Maven, запустив "Проверить как проект Maven..." не в папке, содержащей сам POM, а в родительском каталоге (например, "trunk" ). В этом случае Subclipse проверяет проект без каких-либо претензий, помещая его в каталог рабочей области с именем-заполнителем, например maven.1424425443350. Внутри этого каталога создается подкаталог с именем артефакта Maven. Это смущает Subclipse и Subversion: Subclipse, как мы видели, сразу забывает, что проект находится под управлением версиями, и если вы вызываете svn status из командной строки в каталоге maven.1424425443350, он скажет вам, что каталог находится под управлением версиями, но что все файлы с контролем версий отсутствуют.

Ни одно из обходных решений, представленных в других ответах, не будет работать, если это то, что заставило Subsclipse забыть о его SVN-соединении. Вместо этого единственное решение - удалить проект и снова проверить его, на этот раз убедиться, что проверка выполняется в каталоге, содержащем POM, а не в каталоге более высокого уровня.

Лучшим общим решением было бы для Subclipse отказаться от запуска "Check out as Maven Project..." в каталогах, которые не содержат POM, или лучше обрабатывать случаи, когда он пытается это сделать в любом случае, путем поиска подкаталогов для Проекты Maven.

Ответ 12

Я использовал две реализации SVNKit (1.7.x и 1.8.x) одновременно с версией репозитория SVN (1.8.x).

В результате команды Team → Share... всегда запрашивали сообщение о фиксации. Очевидно, использовался SVNKit 1.7.x, который несовместим с SVN 1.8.x.

После удаления SVNKit 1.7.x eclipse использовала единственную доступную версию SVNKit версии 1.8.x, и все работало, как ожидалось.