Слияние файлов vcproj - ад SCM
Как отметил @FelixKling, наиболее вероятным сценарием является то, что узлы, которые вы ищете, еще не существуют.
Однако современные методы разработки часто могут манипулировать элементами документа за пределами дерева документов либо с DocumentFragments, либо просто отсоединением / повторным подключением текущих элементов напрямую. Такие методы могут использоваться как часть шаблонов JavaScript или для предотвращения чрезмерных операций перерисовки / переплавки, в то время как элементы, о которых идет речь, сильно изменяются.
Аналогично, новая функциональность «Теневой DOM» развертывается в современных браузерах позволяет элементам быть частью документа, но не обрабатываться запросом document.getElementById и всеми его методами sibling (querySelector и т. д.). Это делается для инкапсуляции функциональных возможностей и, в частности, скрыть его.
Опять же, скорее всего, элемент, который вы ищете, просто (пока) в документе, и вы должны сделать, как предлагает Феликс , Тем не менее, вы также должны знать, что это все чаще является не единственной причиной того, что элемент может быть необоснованным (временно или постоянно).
5 ответов
Вы могли бы хотеть рассмотреть соединение Вашего инструмента с триггером в Вашем SCM (как вернуть рычаг для SVN) для осуществления переупорядочения в тех файлах.
Тогда Вы получили бы возможность к эффективному слиянию этих элементов вместе.
-
1Добавление поставщика к модулю doesn' t работают с угловыми 6. Сервисное создание с помощью Углового CLI просто генерирует сервис, не будет обеспечен, это должно быть обеспечено, чтобы использоваться. – Vinutha Kumar 4 October 2018 в 09:33
Я обычно стараюсь не подвергать автоматически сгенерированные файлы SCM. Автоматически сгенерированные файлы должны быть сгенерированы от исходных файлов, которыми управляет разработчик, и те могут быть подвергнуты SCM. Если конкретный инструмент хранит данные в непрозрачном и хрупком формате, это - проблема инструмента.
Относительно Visual Studio, хотя я думаю, что она имеет достойные компиляторы, библиотеки и среду отладки, я полагаю, что файлы в генерируют (PRJ, SLN, RC) очень проблематичны. Кроме проблем Вы упоминаете, они также изменяются много между различными версиями VS. Поэтому мы пишем наши собственные make-файлы и создаем программы внешне, использование делают. Кроме того, мы разделяем файлы ресурсов на части, для которых мы вынуждены полагаться на VS, и те мы можем нормально обработать с нормальным редактором. Мы генерируем много файлов ресурсов автоматически из высокоуровневого описания, записанного на пользовательских проблемно-ориентированных языках. Мы таким образом минимизируем влияние изменений, которые трудно обработать под SCM.
-
1Я часто добавляю - справка или - пробный прогон в конце команды ng, прежде чем я приму на себя обязательство выполнять его. Отличный способ учиться и помнить опции. Обратите внимание, что нижний регистр пробного прогона doesn’t работает! – Simon_Weaver 5 September 2018 в 10:11
Я создал инструмент для сравнения и объединения файлов решений ( http://slntools.codeplex.com ). Гораздо проще объединить решение с инструментом, чем с обычным слиянием. Он не может обрабатывать файлы проекта.
Что мы делаем с файлами ресурсов (с файлами проектов не так много проблем), так это сортируем их перед слиянием. Мы настроили команду слияния на Plastic, чтобы она действительно выполняла сортировку (для этого мы разработали другое приложение, мы можем поделиться кодом, если вам интересно, ничего сложного) перед слиянием, так что все случайные перемещения исчезают... Надеюсь, это поможет.
Проект: Merge - это мой инструмент для сравнения и слияния XML файлов. Изначально я написал его, потому что у меня была именно такая проблема с файлами проектов Visual Studio.
Он правильно обнаруживает переупорядоченные элементы и/или атрибуты в XML-файле и автоматически разрешает почти все "конфликты".