VS2008 и ClearCase: вводное решение запрашивает контроль ни по какой причине
После step7,
Откройте командную строку и перейдите в каталог сценариев Java и выполните команду: - npm install protractor (эта команда загрузит папку node_modules внутри каталога вашего проекта)
Затем продолжите с другими шагами.
Надеюсь, это поможет вам
Если это не удастся, попробуйте выполнить шаги из https://github.com/angelozerr/angularjs-eclipse/wiki/Protractor
4 ответа
Хорошо, я нашел решение проблемы, и это было довольно просто в действительности.
Я отключил интеграцию Visual Studio ClearCase на сервере сборки.
VS используется, поскольку мы должны разработать проекты развертывания и таким образом, мы называем devenv, чтобы сделать это для нас. Однако мы только используем его в качестве механизма сборки, никогда нет потребности в механизме сборки, чтобы знать, как изменить исходные объекты, поскольку они все просто прибудут из ClearCase. Единственные объекты, которые мы позволяем серверу сборки изменять, являются атрибутами номера версии файла блока в файлах AssemblyInfo, но мы делаем это в NAnt а не в Visual Studio.
Так, отключите функциональность, и проблема уходит. Вероятно, не решение для всех, но на сервере сборки это был путь вперед.
Это, кажется, нормально для VS2008, он проверяет .sln файл при открытии решения. Мне не нравится он также.
Вашей проблемой однако является то, что в .suo файле также регистрируются. Этот файл не должен быть помещен при управлении исходным кодом. Это похоже на proj.user файлы. Я подозреваю, что suo обозначает Пользовательские Опции Решения.
Вы могли:
- обновите свой сценарий для угона sln файла в представлении снимка сразу после"
cleartool update -force -overwrite". - или, для предотвращения sln, который будет проверен, Вы могли попытаться сохранить .suo файл зарегистрированным,
Если вышеупомянутое предложение работает, то вот несколько причин, почему можно было бы хотеть сохранить этот файл при управлении версиями:
Так как .suo файл доступен (VS2008 просто создает новый, если он не существует), имение при управлении исходным кодом могло бы рассматриваемый как способ избежать, что создание (следовательно избегающий плагина ClearCase обнаружение его и пробующий к тому, "добавляют к управлению исходным кодом" он или проверке его).
Другое преимущество для наличия .suo файл при управлении версиями (но не обновленное через дальнейший контроль/регистрацию) состоит в том, когда Вы выдерживаете сравнение, Ваш проверенный проект с другим проверил версию того же проекта, загруженного в другом месте: тот файл всегда будет идентичен, в противоположность систематически отличающемуся (так как, если бы двоичный файл и какая-либо новая версия двоичного файла, зарегистрировал бы себя как отличающийся),
Этот элемент устранения неполадок привел меня к этому пакету исправлений, который решил проблему в нашей среде разработки. Мы все еще используем VS2005, но я ожидаю, что это та же проблема, что и в VS2008.