Слияние с файлами IntelliJ IDEA.IPR и .IWS

Ответ 1

"Мы сохраняем наши файлы IntelliJ.IPR и .IWS в нашем исходном элементе управления, но они постоянно меняются IntelliJ, просто открывая их, даже без какой-либо работы над проектом".

Файл .IWS определенно является файлом для каждого разработчика, поэтому он не должен находиться под контролем источника.

Что касается файла .IPR в недавнем проекте, мы изначально пытались довести этот файл до концептуального подхода, как это было бы с проектом .Net и VS.Net файлом VS.Net. Наша цель состояла в том, чтобы завести разработчика на чистый компьютер в течение 15 минут, включая время, необходимое для установки зависимого программного обеспечения, такого как IDE или локальная база данных. В конце мы подошли ближе с некоторым временем, чтобы настроить локальную конфигурацию, как показано ниже.

Проблема заключается в том, что файл .IPR хранит больше параметров, чем настройки .sln файла -eg для отдельных плагинов. Поэтому основной причиной перезаписывания является то, что разработчик с другой конфигурацией плагина открывает файл IPR. В файл записываются некоторые настройки по умолчанию для плагина. Мы чувствовали, что разработчикам не нужно ограничивать себя определенным набором плагинов (только минимальная конфигурация).

То, как мы разрешили проблему (хотя и не полностью решена), заключалось в том, чтобы переключиться на формат папки .idea. Это занимает содержимое файла .IPR и разбивает многие узлы на отдельные файлы и папки в подпапке .idea. Отсюда мы смогли исключить многие из часто записанных файлов из исходного управления. Некоторые из файлов, которые мы исключили, были:

• workspace.xml
• dataSources.xml
• sqlDataSources.xml
• dynamic.xml

Некоторые файлы, которые хотели бы, чтобы IntelliJ остался один, (хотя вину также могут пойти разработчики плагинов, а не только Jetbrains):

• projectCodeStyle.xml(чтобы мы могли получить согласованное форматирование кода в проекте - снова это может быть перезаписано на основе локального плагина для разработчиков).
• любой файл в папке runConfigurations. Может потребоваться много времени для настройки конфигурации запуска, особенно если у вас есть сложное приложение со многими аспектами. Чаще всего глупое дело, которое меняется, просто открывая IDE или здание - это опция "DEBUG_PORT" в RunnerSettings. Мое мнение, если оно динамически распределено, почему бы не иметь значение "Динамический"?
• misc.xml. Этот файл также содержит конфигурацию плагина. Некоторые настройки удобны для совместного использования, а другие больше подходят для личной конфигурации. Например, плагин IvyIDEA устанавливает абсолютный путь к вашему конфигурационному файлу плюща.
• Файлы модулей. Они в основном оставлены в покое, но примером ненужной перезаписи является плагин IvyIDEA, в котором размещаются сведения о локальном местоположении плюща-плюса в этом файле. Но опять же это ошибка плагина, а не Jetbrains.

Надеюсь, что это поможет.

Кристиан.

Ответ 2

Не зная точно, что меняется, это немного сложно ответить уверенно, но я бы сказал:

• Файлы IWS содержат информацию, описывающую, как для этого проекта организована IDE разработчика (включая такие вещи, как недавняя история изменений, текущее состояние каждого окна редактора, какие прикрепляемые окна видны и которые были свернуты). Учитывая, что каждому разработчику должно быть разрешено упорядочить свое рабочее пространство, как им нравится, эти не должны находиться в исходном управлении.

• IPR файлы описывают структуру кода проекта - я имею в виду такие вещи, как модули, которые являются частью проекта, какие файлы build.xml использовать, где искать библиотеки для компиляции кода и т.д. Это может быть в контроле источника, но если вы разрешите этим настройкам меняться от одной копии разработчика проекта до следующей, вы будете в грубой поездке.

Если у вас есть файл libraryTable внутри вашего IPR файла:

Почти наверняка, что происходит, каждый разработчик хранит разделяемые библиотеки (JAR) - необходимые для создания своего кода - на своей локальной машине в разных местах; когда они фиксируют изменения, расположение их библиотек записывается в файл IPR. Если бы вы сделали это, когда я обновил проект, моя копия права интеллектуальной собственности и вашего конфликта будет конфликтовать с местоположениями этих JAR.

Мы сталкиваемся с этой проблемой, размещая файлы JAR в общем местоположении (например, подключенный сетевой диск), а затем гарантируя, что каждый разработчик загружает эти файлы в одно и то же место (подпапка lib в корне проекта хорошо работает). Недостатком является то, что вы получаете несколько копий одного и того же JAR по проектам (каждый проект будет ссылаться на свою собственную папку lib), но, с другой стороны, поскольку каждый разработчик использует ту же структуру проекта, обновление IPR должно работать намного лучше.

В противном случае:

Посмотрите, что пытается интегрировать IntelliJ (при обновлении вам должна быть предоставлена ​​возможность вручную объединить файлы или просмотреть различия, иначе используйте свой любимый инструмент diff). Если бы вы могли обновить свой вопрос немного подробнее о том, как выглядят конфликты слияния, это может облегчить просмотр колес.

Ответ 3

Мы добавляем расширение к тем, которые были проверены в исходном элементе управления (.deleteme). Затем новые люди могут проверить проект, изменить расширения и уйти. Если мы вносим изменения в конфигурацию, мы обновляем проверенные файлы.

Ответ 4

Одно из решений - не включать проекты IntelliJ в исходный контроль. Это означает, что их легко воссоздать.

Вы можете сказать Subversion о файлах, которые он должен игнорировать. Добавьте файлы IntelliJ в этот список.

"... даже без какой-либо работы над проектом..." - это говорит о том, что вы часто открываете IntelliJ без какой-либо полезной работы над проектом. Возможно, это настоящая проблема. Я не понимаю, почему вы открыли IDE, не делая SOMETHING, что было бы целесообразно проверить. И какова стоимость растущего номера ревизии? Маленький, по-моему.

Итак, теперь я передумал. Проверьте файлы проекта IntelliJ и не беспокойтесь о растущих номерах ревизий. Они не очень ценят вас.