Объединяет файлы IntelliJ IDEA .IPR и .IWS

Question

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

Что мы делаем не так?

Answer 1

"Мы сохраняем наши файлы 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 устанавливает абсолютный путь к вашему файлу конфигурации ivy.
• Файлы модуля. Они в основном оставлены в покое, но примером ненужной перезаписи является плагин IvyIDEA, который помещает сведения о локальном расположении кэша плюща в этот файл. Но опять же, это ошибка плагина, а не Jetbrains.

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

Christian.

Answer 2

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

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

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

Если в вашем файле IPR есть компонент libraryTable:

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

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

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

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

Answer 3

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

Answer 4

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

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

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

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