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

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

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

Что касается файла .IPR в недавнем проекте, мы изначально пытались реализовать этот файл, концептуально приближаясь к нему, как с проектом .Net и VS.Net .SLN-файлом. Наша цель состояла в том, чтобы завести разработчика на чистый компьютер в течение 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.

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

Кристиан.

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

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

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

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

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

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

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

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

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

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

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

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

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