Как управлять внешними зависимостями, которые постоянно изменяются
Вы должны поместить :after внутрь .selected: посмотреть эту скрипку
.circle {
border-radius: 50%;
box-sizing: border-box;
width: 225px;
height:225px;
border: 6px solid #ff6600;
border-radius: 50%;
position: relative;
cursor:pointer;
&.selected {
border: 6px solid #0066ff;
&:after { // <-- moved this inside .selected
border-top-color: #0066ff;
}
}
// rest of the styles...
}
5 ответов
Я сохраняю их в svn и управляю ими, поскольку поставщик переходит. Хранение их свободный внешне делает его очень трудно, чтобы вернуться к предыдущей сборке или исправить ошибки в предыдущей сборке (особенно, если ошибка от изменения до внешней зависимости),
Хранение их в svn сохранило меня много головной боли и также позволяет Вам получать новую рабочую станцию, которая в состоянии работать над Вашей кодовой базой быстро.
Я не понимаю, почему Вы говорите
Я не хочу помещать их в наш репозиторий, потому что я не смогу обновить их тот путь. Некоторые из них постоянно обновляются.
Вы действительно должны
включайте внешние зависимости в свое управление исходным кодом и периодически обновляйте их и затем их, тест, тест.
Скоординируйте свой процесс сборки с обновлениями для внешних зависимостей.
Если Ваш код зависит от чего-то, то действительно необходимо управлять, когда он обновляется/изменяется. Кодирование в пространстве, где эти зависимости могут быть обновлены в любое время, является слишком болезненным, как Вы несомненно узнаете. Я лично предпочитаю опцию 1.
Когда я должен был сделать что-то вроде этого, я добавил внешний источник как внешний, и затем применил патч к нему. Патч содержит мои модификации к внешнему источнику. Так, я на самом деле только управление версиями мои патчи. Большинство времен это работает, при отсутствии "поразительных" изменений во внешнем коде.
Вы рассмотрели Знатока? Это - система сборки, которая имеет превосходную поддержку руководящих зависимостей. Для каждого проекта можно указать необходимые зависимости в XML-файле как часть того проекта. Внешние библиотеки сохранены в репозитории зависимости (в нашем случае Artifactory), это является отдельным от Вашей системы управления версиями и может просто быть сетевым диском. Это также позволяет управлять различными версиями проектов.
Я был бы осторожным Знатоком рассмотрения потому что:
- это - другой репозиторий в системе, где у Вас уже есть репозиторий с Вашей системой управления текущей версии;
- это (Знаток) основано на единственном "общем управлении версиями" каждый разработчик, имеют, файловая система (что не означает метаданных или свойств, присоединенных к файлу, никакой надлежащей истории с точки зрения того, кто изменил какой и когда),
Теперь при контакте с третьими лицами, можно рассмотреть наличие их в системе управления версиями, но упакованным способом: это находится очень компактным способом с источниками и заархивированной документацией, чтобы иметь наименее возможное количество файлов.
Тем путем Вы справитесь с развертыванием тех (много) сторонние библиотеки легко, так как количество файлов для развертывания является небольшим.
Плюс, имея их при управлении исходным кодом позволяет Вам делать ответвление (скажите, ответвление 'взлома'), в котором Вы будете, сохранил упакованный (или архивировал), версия взломанной библиотеки.
То, что можно сохранить внешним способом, является разархивированным, полным набором файлов, представляющих те библиотеки, так как нет никакой реальной разработки на них или просто пунктуального взлома: обычно, Ваше задание не состоит в том, чтобы разработать существующие библиотеки, но использовать их (даже немного измененный) для реализации быстрее некоторых функций Вашего проекта.
Если необходимо в какой-то момент сравнить некоторую взломанную версию с некоторой официальной версией, Вы просто вытащите из svn соответствующий 'взломанный' номер версии, разархивируете - он и соответствовать - он чиновнику (и внешне сохраненный) версия (с winmerge, например)