Мы сохраняем наши файлы IntelliJ .IPR и .IWS в нашем исходном контроле, но они продолжают модифицироваться IntelliJ, просто открывая их, даже без какой-либо работы над проектом.Слияния в файлах IntelliJ IDEA .IPR и .IWS
Что мы делаем неправильно?
Одним из решений является не поместить ваши проекты IntelliJ в исходный контроль. Это означает, что их легко воссоздать.
Вы можете указать Subversion о файлах, которые он должен игнорировать. Добавьте свои файлы IntelliJ в этот список.
«... даже без какой-либо работы над проектом ...» - это говорит о том, что вы часто открываете IntelliJ без какой-либо полезной работы над проектом. Возможно, это настоящая проблема. Я не понимаю, почему вы открыли IDE, не делая SOMETHING, что стоит проверить. И какова стоимость растущего номера версии? Маленький, по-моему.
Итак, теперь я передумал. Проверьте файлы проекта IntelliJ и не беспокойтесь о растущих номерах ревизий. Они не очень ценят вас.
Не зная точно, что изменяется, это немного трудно ответить уверенно, но я бы сказал:
IWS файлы содержат информацию, описывающую, как IDE разработчик является организовал для этого проекта (в том числе такие истории, как недавняя история изменений, текущее состояние каждого окна редактора, которые прикрепляются к окнам и которые были свернуты). Учитывая, что каждому разработчику должно быть разрешено организовывать свою рабочую область, как им нравится, эти не должны находиться в исходном управлении.
IPR файлы описывают структуру проекта код - под этим я имею в виду такие вещи, как, какие модули являются частью проекта, который build.xml файлы использовать, где найти библиотеки для компиляции кода и т.д. Это может быть в исходном режиме, но если вы позволите этим настройкам меняться от одной копии проекта разработчика к другому, вы будете в грубой поездке.
Если у вас есть libraryTable компонент внутри файла IPR:
Почти наверняка, что происходит в том, что каждый разработчик хранит общие библиотеки (баночки) - требуется построить свой код - на их местном машина в разных местах; когда они фиксируют изменения, расположение их библиотек записывается в файл IPR. Если бы вы сделали это, когда я обновил проект, моя копия ПИС и вашей будет конфликтовать по местам этих JAR.
Мы сталкиваемся с этой проблемой, размещая файлы JAR в общем местоположении (например, подключенный сетевой диск), а затем гарантируя, что каждый разработчик загружает эти файлы в одно и то же место (подпапка lib в корне проекта хорошо работает). Недостатком является то, что вы получаете несколько копий одного и того же JAR по проектам (каждый проект будет ссылаться на свою собственную папку lib), но, с другой стороны, поскольку каждый разработчик использует ту же структуру проекта, обновление IPR должно работать намного лучше.
Иначе:
Посмотрите, чтобы увидеть, что IntelliJ пытается объединить (при обновлении, вы должны быть предоставлена возможность вручную объединить файлы или просматривать различия, в противном случае использовать ваш любимый инструмент сравнения) , Если бы вы могли обновить свой вопрос немного подробнее о том, как выглядят конфликты слияния, это может облегчить работу с колесами.
«Мы сохраняем наши файлы IntelliJ .IPR и .IWS в нашем исходном контроле, но они постоянно изменяются IntelliJ, просто открывая их, даже без какой-либо работы над проектом».
Файл .IWS определенно является файлом разработчика, поэтому он не должен находиться под контролем источника.
Что касается файла .IPR в недавнем проекте, мы изначально пытались доработать этот файл концептуально, как вы бы с проектом .Net и VS.Net .SLN-файлом. Наша цель состояла в том, чтобы завести разработчика на чистый компьютер в течение 15 минут, включая время, необходимое для установки зависимого программного обеспечения, такого как IDE или локальная база данных. В конце концов, мы подошли с некоторым временем, чтобы настроить локальную конфигурацию, как показано ниже.
Проблема заключается в том, что файл .IPR хранит больше настроек, чем настройки .sln-файла -eg для отдельных плагинов. Поэтому основной причиной перезаписывания является то, что разработчик с другой конфигурацией плагина открывает файл IPR. В файл записываются некоторые настройки по умолчанию для плагина. Мы чувствовали, что разработчикам не нужно ограничивать себя определенным набором плагинов (только минимальная конфигурация).
Способ устранения проблемы (хотя и не полностью решена) заключался в том, чтобы переключиться на формат папки .idea. Это занимает содержимое файла .IPR и разбивает многие узлы на отдельные файлы и папки в подпапке .idea. Отсюда мы смогли исключить многие из часто записанных файлов из исходного управления. Некоторые из файлов, мы были исключены:
Некоторые файлы, которые мы хотели бы оставить IntelliJ (хотя вину также могут пойти разработчики плагинов, а не только Jetbrains):
Надеюсь, что это поможет.
Христианство.
Какой замечательный ответ. – Kieveli
Да - отличный ответ! На форуме Jetbrains ваше решение исключить файл workspace.xml поддерживается: http://devnet.jetbrains.net/message/5252427 (Они также предлагают исключить tasks.xml при использовании формата .idea). –
Мы добавляем расширение к тем, которые были проверены в исходном элементе управления (.deleteme). Затем новые люди могут проверить проект, изменить расширения и уйти. Если мы вносим изменения в конфигурацию, мы обновляем проверенные файлы.
Но они содержат структуру проекта! Мы используем их (по крайней мере, IPR) в процессе автоматической сборки, а также таким образом, когда один разработчик меняет модуль, другие разработчики получают его изменения. Это похоже на сохранение .sln-файла в исходном элементе управления .NET, который является рекомендуемой лучшей практикой. – ripper234
Не так сложно воссоздать. – duffymo
Если не поставить в исходный элемент управления, не каждый разработчик должен поддерживать свою собственную версию и синхронизироваться с изменениями, внесенными другими разработчиками? – ripper234