У меня есть проект в subversion, который я разрабатываю с помощью Eclipse. Я сделал оригинальную проверку из репозитория svn из Eclipse. Все было хорошо в течение нескольких недель, тогда по какой-то неизвестной причине Eclipse (в частности: subclipse в Ganymede) больше не признает мой проект под управлением svn. В контекстном меню команды отображаются только основные параметры меню "apply patch" / "share this project". Из оболочки я все еще могу обновить проект, используя инструменты командной строки svn, поэтому я знаю, что учетные данные svn все еще работают. Другие проекты под подрывной деятельностью в той же копии Eclipse все еще работают.
Я понимаю, что я могу удалить локальную копию и проверить ее снова, но я бы лучше понял, что пошло не так - исправить проблему, а не маскировать симптомы. Где Eclipse хранит свои знания о том, какие проекты находятся под контролем версий? Я просмотрел файл .project и каталог .settings, но не мог видеть никаких очевидных упоминаний о природе svn или чем-то подобном, даже в проектах, которые все еще работают должным образом.
Если вы используете сублипсу в качестве поставщика SVN, я рекомендую сделать следующее
Team → Share project обычно достаточно для соединения метаданных.
(то есть, считая, что файлы .svn все еще существуют, что они, кажется, есть, если вы можете работать в командной строке).
Надеюсь, что это поможет, почему это произойдет, я понятия не имею
Я нашел простой способ только reimport проекта
Просто команда 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, и он успешно восстановил соединение.
Приложение: выясняется, что моя проблема проявляется, когда я запускаю Eclipse вне компании vpn, с проектом в рабочей области, который привязан к репозиторию svn внутри vpn. К счастью, переключение плагинов Eclipse svn с подрывной подзаймы действительно разрешило его.
Ян
Из затмения я закрыл проект и снова открыл, что разрешило проблему. Все ссылки SVN возвращаются для всех проектов в моей рабочей области.
У меня была такая же проблема, и этот форум помог мне найти правильный ответ.
Мой предыдущий проект был настроен с использованием подзаголовка. Новое затмение имело subvesive.
Установка подзаголовка помогла мне вернуть параметры svn в команде!
Надеюсь, что это поможет кому-то другому.
рассматривает
Аньшу Пратеек
Не зная, на какой платформе вы работаете, я не знаю, похожа ли ваша проблема на мою. Тем не менее, я недавно (фактически на двух разных платформах!) Имел проблемы, когда обновление Subversive (или, возможно, самого Eclipse, непонятное) приводило к тому, что разъемы больше не загружались. Без соединителей Subversive не может подключиться к проекту. Но Eclipse не собирается блокировать вас от вашего проекта, так как он просто удалит связанные с SVN функции.
Посмотрите на представление "Ошибки", которое представляет собой журнал различных ошибок Eclipse (исключения, не найденные в классе и т.д.), и посмотрите, есть ли какие-либо строки, относящиеся к компонентам Subversive. К сожалению, я не могу рекомендовать решение - на моей платформе Mac OSX этого было достаточно, чтобы переустановить базовые элементы и разъемы Subversive. На моей машине Linux (возможно, из-за обновления ОС) мне нужно полностью переустановить Eclipse, так как для меня было достаточно большого количества трещин, чтобы иметь возможность полностью исследовать ее.
В выпуске Juno с Subversive я сделал:
Затем он "импортирует" ваш существующий каталог, который может быть использован на месте, который уже находится внутри вашего каталога рабочей области.
То же самое в моем случае:.svn dirs были там, но мой проект не поддерживал действия svn.
После немного выкалывания оказалось, что подрывный плагин просто исчез после принудительного закрытия затмения.
Решение заключалось в (re) установке подрывной функции, и теперь все хорошо.
Приветствия v.
UPDATE: я переключил eclipse на новую версию, у которой просто не был установлен плагин, поэтому я должен был установить его с нуля.
Это сработало для меня: щелкните правой кнопкой мыши- > TortoiseSVN → Настройки → Значок Наложение свойств, Выбор Shell как кэш состояния. Нажмите "ОК", "Обновить страницу".
Я могу достоверно воспроизвести эту проблему - это происходит при проверке определенных проектов 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.
Я использовал две реализации 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, и все работало, как ожидалось.