Hello Esko,

I noticed that the latest EAP has a menu item "File | Open in New

(Directory Based) Format". What does it do? What is that new format

and how does it work? When does it make sense to use it?

 

I tried it once and it seems that it created a ".idea" directory with

lots of config files under the project root directory. I did not

understand its benefits, so I reverted the changes.

The main benefit of the directory-based format is avoiding merge conflicts

when working in a team. Each logically independent piece of the configuration

is stored in a separate file, so, for example, when someone updates an inspection

profile and you have some local changes in a shared run configuration, there's

no merge operation involved.

--

Dmitry Jemerov

Development Lead

JetBrains, Inc.

http://www.jetbrains.com/

"Develop with Pleasure!"

Hello Stephen,

The conversion doesn't delete anything. If a directory contains both the

.ipr file and the .idea directory, .idea takes precedence.

Most likely you will want to delete the .ipr file manually and ask your colleagues

to reload the project, but this is just a one-time inconvenience which brings

many subsequent benefits.

Hm, will the update work smoothly as far as team collaboration is

concerned?

- I update the project to use the directory based format

- IDEA deletes the *.ipr (and *.iml?) files from disk

- I commit (IDEA commits the project files deletion and the project

directory addition)

- my coworkers update

- on their machines IDEA detects the missing project files and the new

project directory

Or will I have to tell everybody to shut down IDEA, update, then load

the project from a different place?

(Would be kind of strange for a feature that should ease collaboration

via vcs.)

Dmitry Jemerov wrote:

 

>> Hello Esko,

>>

>>> I noticed that the latest EAP has a menu item "File | Open in New

>>> (Directory Based) Format". What does it do? What is that new format

>>> and how does it work? When does it make sense to use it?

>>>

>>> I tried it once and it seems that it created a ".idea" directory

>>> with lots of config files under the project root directory. I did

>>> not understand its benefits, so I reverted the changes.

>>>

>> The main benefit of the directory-based format is avoiding merge

>> conflicts when working in a team. Each logically independent piece of

>> the configuration is stored in a separate file, so, for example, when

>> someone updates an inspection profile and you have some local changes

>> in a shared run configuration, there's no merge operation involved.

>>

--

Dmitry Jemerov

Development Lead

JetBrains, Inc.

http://www.jetbrains.com/

"Develop with Pleasure!"

Hello Justin,

Yes, the .iws file can be deleted.

Your colleagues do not need your workspace.xml file because it contains settings

specific to your workspace. You should never store .iws or workspace.xml

files in version control systems.

Sorry to dig this up from January, but what about the *.iws file? Can

that be deleted as well so that only the *.iml file remains? The .idea

directory that is created in the conversion contains a workspace.xml

file that has the same contens as the *.iws file however the

.idea/workspace.xml file is b

 

locked is on the ignore list and can't be checked in unless I override

it. This is great later on, but if I commit my new .idea directory to

SVN and the rest of my team downloads it, where will they get the

workspace.xml file?

 

Btw: This thread would be a good candidate to be rewritten into the

FAQ as this is the only place in the community that I've found

information about how to convert from the .ipr file based config to

the new .idea directory based configs.

 

- Justin

 

---

Original message URL:

http://www.jetbrains.net/devnet/message/5240792#5240792

--

Dmitry Jemerov

Development Lead

JetBrains, Inc.

http://www.jetbrains.com/

"Develop with Pleasure!"

Hello Jean,

All files except for workspace.xml are designed to be stored in source control.

we're using the directory-based format for our project, and running

build #9902 (that fixes an issue where the .idea sub-directories were

overwritten by IDEA and losing their own .svn sub-directories in the

process, making them hard to source-control). What are best practices

about what to source-co

 

ntrol (thus share) what not to? Intuitively, it seems that we'd want

to share anything that doesn't contain developer specific settings

(such as file paths), but things might be subtler than that. Is there

any documentation about which files and directories under .idea should

be source-controlled?

--

Dmitry Jemerov

Development Lead

JetBrains, Inc.

http://www.jetbrains.com/

"Develop with Pleasure!"

Hello Jean,

Which VCS integration are you using in IntelliJ IDEA?

Thanks for your prompt reply,

I noticed the following fragment in .idea/misc.xml:

<component name="ProjectKey">

<option name="state" value="project://C:\Blah\.idea\misc.xml" />

</component>

with C:\Blah being developer- and project-dependent.

 

Am I doing something wrong in terms of project settings, as it seems

this path might be problematic on others' machines?

--

Dmitry Jemerov

Development Lead

JetBrains, Inc.

http://www.jetbrains.com/

"Develop with Pleasure!"