What is "Open in New (Directory Based) Format"?

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.

--
Esko Luontola
www.orfjackal.net

0
16 comments

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!"


0
Avatar
Permanently deleted user

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.

0

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!"




0
Avatar
Permanently deleted user

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 blocked 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

0

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!"


0
Avatar
Permanently deleted user

Hi Dimitry,
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-control (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?
Thanks,
Jean

0

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!"


0
Avatar
Permanently deleted user

Hi Dmitry,

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?

Thanks,

Best regards,

Jean



 

0

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!"


0
Avatar
Permanently deleted user

Hi Dmitry,
We use the built in Subversion integration feature in IntelliJ IDEA (#9902). We also use the Tortoise SVN client
Under File/Settings -> Version Control / VCS / Subversion, we checked the "Use system default Subversion configuration directory" box.
Thanks,
Jean

0
Avatar
Permanently deleted user

Hi Dmitry,
let me know if you need more information about our project settings.
This absolute path is the only one appearing in misc.xml, or any file within .idea and its subfolders, by the way.Everything else is using the $PROJECT_DIR$ variable.
Incidentally, we use the "relative paths" setting for both the project itself and its modules.
Best regards,
Jean

0
Avatar
Permanently deleted user

Dmitry,

What is the purpose of the "ProjectKey" entry?  I have this entry in misc.xml:

  <component name="ProjectKey">
     <option name="state" value="our.perforce.hostname:1666://" />
   </component>

Will there be any problems if other developers use this?  I think I read somewhere that this has something to do with file indexing/caching or something like that...

Edit: After I open the re-opened the project, IntelliJ modifies the misc.xml and changes the ProjectKey:

<component name="ProjectKey">
    <option name="state" value="C:\MyProjectDirectory\.idea\misc.xml" />
  </component>

0

Hello Anthony,

The project key is used for storing workspace files on the settings sharing
server. You can disable the IDEA Server plugin if you don't use this functionality
and don't want the entry to appear.

What is the purpose of the "ProjectKey" entry? I have this entry in
misc.xml:

<component name="ProjectKey">
<option name="state" value="our.perforce.hostname:1666://" />
</component>
Will there be any problems if other developers use this? I think I
read somewhere that this has something to do with file
indexing/caching or something like that...


--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Avatar
Permanently deleted user

I'm running into an issue with misc.xml getting changed when a collegue pulls this file from Perforce.

Should this file be checked into a SCM if we wish to share settings or should it be off limits like workspace.xml should be?

It seems my collegue picked up changes from the Idea Server settings.

0

Hello Shane,

misc.xml is supposed to be sharable. What exactly changed in the file?

I'm running into an issue with misc.xml getting changed when a
collegue pulls this file from Perforce.

Should this file be checked into a SCM if we wish to share settings or
should it be off limits like workspace.xml should be?

It seems my collegue picked up changes from the Idea Server settings.


--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Avatar
Permanently deleted user

Dmitry,

One additional piece of information is that I found that my collegue had the Idea Server Plugin enabled but I did not. Would the plugin being enabled impact this issue?

Here are examples of what changes occur in misc.xml:

<UsedPathMacros>
    <macro name="HOME" />

changes to:

<UsedPathMacros>
    <macro name="HOME" description="" />


Also, this element changes from:

<component name="ProjectKey">
    <option name="state" value="project://default" />
  </component>

to:

<component name="ProjectKey">
    <option name="state" value="nyggmmbsd1:11666:////depot/spg/beaver/.idea/misc.xml" />
</component>


I believe there were other changes in addition to the above.

Thanks,
Shane

0

Please sign in to leave a comment.