modifications to ipr file and cvs

On Tue, 04 Mar 2003 16:12:47 -0600, Barry Kaplan wrote:

Related to this, when doing a cvs update, and ths ipr file has changed in
the repository, those changes will be lost if idea is running when the
update was performed (because idea already has the previous version in
memeory, and since idea always seems to modify the ipr, the memory version
is overwritten on disk, losing the just updated changes from cvs). Do any
other teams have this difficulty?

Seen this, hated this. Esp. when using Perforce and the .ipr isn't in
edit mode.

At work all our builds are controlled by the Ant build.xml file, and the
project files arn't actually in CVS, there just on the developers machine.
Not all of our developers are using IntelliJ ( one insists on using Net
Beans ).

This is a work-around, would be nice having the project in the repo thou.
Maybe moving these plugin settings that arn't "project build" specific can
be stored in another project related file, say projectxxx.opt - that file
can then be left out of CVS.

Here is what we do. We've created a template .ipr file which is checked in. When someone first starts on the project, they are able to copy it to the project home directory and get started with most everything working. They usually just have to set up CVS and point to the correct JDK. We have people developing on several different platforms, so there is just no way we can use the same .ipr without a lot of problems.

To make the .ipr, I make sure that I have Idea set up to use relative paths. You'll still have to go in and make some mods if you have some stuff which is not in the project hierarchy. For instance, I might have a file listed as:

/home/tim/framework/src

even with relative paths set for a project in /home/tim/project. I would just change this to

$PROJECT_DIR$/../framework/src

Going a step further, you could write an ant target which took this template .ipr and copied it to the proper location with replacement of tags which you've put in there with proper directory information for stuff like the JDK.

This doesn't make it easy to deal with changes that happen after someone starts using the template .ipr, however. But it is nice to get started with.

Could you please analyze the differences which are typically made to the ipr
file and find which settings are changed? The ipr file is in xml format and
it should not be hard to do this.

--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"


"Barry Kaplan" <bkaplan@integratedtrading.com> wrote in message
news:3E6524DF.7010702@integratedtrading.com...

We see in our team that the ipr file thrashes constantly. It seems that
all kinds of user preferences -- both from idea and plugins -- are
stored in the ipr file. Thus everytime we commit to cvs the ipr file is
marked as modified, and we have to do a compare to see if the changes
are relevant to the team or not. Do any other teams have this difficulty?

>

Related to this, when doing a cvs update, and ths ipr file has changed
in the repository, those changes will be lost if idea is running when
the update was performed (because idea already has the previous version
in memeory, and since idea always seems to modify the ipr, the memory
version is overwritten on disk, losing the just updated changes from
cvs). Do any other teams have this difficulty?

>

Valentin Kipiatkov wrote:

Could you please analyze the differences which are typically made to the ipr
file and find which settings are changed? The ipr file is in xml format and
it should not be hard to do this.

Here are some samples:

1. This some classpath entry seem to always get an extract 'file:'
preprended.

from:
to: from: to: ]]>

2. The state of the ant view (ie, the filter state) is stored in the ipr
file instead of the iws file. This causes thrashing.

3. : Some plugins store information in the
ipr file. Since not everybody uses the same set of plugins, this causes
trashing:
- - ]]>


There are lots more. I can continue to supply examples if needed.

-bk

Another thrashpoint is the code style scheme. Although it makes sense
for this value to be set in the ipr file, the scheme itself is not
sharable. (When I say not sharable, I mean I can't store in the project
tree and check it into CVS.) So if one team member does not have the
"agreed upon" code style in his local settings directory, the project
will setting will revert back to "default". If the code style were
sharable, this thrashing would not occur.

Barry,

1. This some classpath entry seem to always get an extract 'file:'
preprended.

>

from:
<entry

>
path="file://file://file://file://file://file://file://file://file://file://
file://file://file://file://file://file://file://file://file://file://file:/
/file://file://file://file://file://file://file://file://file://file://file:
//file://file://file://file://file://file://$PROJECT_DIR$/../../../deploymen
t/appserver/its/conf/exchange/testset1"

/>

There was a bug in some of EAP Ariadna versions, which caused such a
behaviour. It shouldn't be reproducible in a fresh
project. If it does, please tell me the absolute paths for your .ipr file &
roots, which cause this behaviour.

--
Best regards,
Mike Aizatsky.
-

JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"

I have this same problem and wrote it up as bugs 8457 and 7450.

"Barry Kaplan" <bkaplan@abwg.com> wrote in message
news:b4lcsb$s62$1@is.intellij.net...

Another thrashpoint is the code style scheme. Although it makes sense
for this value to be set in the ipr file, the scheme itself is not
sharable. (When I say not sharable, I mean I can't store in the project
tree and check it into CVS.) So if one team member does not have the
"agreed upon" code style in his local settings directory, the project
will setting will revert back to "default". If the code style were
sharable, this thrashing would not occur.

>
>

Mike Aizatsky wrote:

Barry,

>>1. This some classpath entry seem to always get an extract 'file:'
>>preprended.
>>
>>from:
>>>]]>

path="file://file://file://file://file://file://file://file://file://file://
file://file://file://file://file://file://file://file://file://file://file:/
/file://file://file://file://file://file://file://file://file://file://file:
//file://file://file://file://file://file://$PROJECT_DIR$/../../../deploymen
t/appserver/its/conf/exchange/testset1"

>>/>

There was a bug in some of EAP Ariadna versions, which caused such a
behaviour. It shouldn't be reproducible in a fresh
project. If it does, please tell me the absolute paths for your .ipr file &
roots, which cause this behaviour.

Ok, it has happened again:

from:
to: ]]>


The absolute path for the project is:
c:/cvs.local/its.dev/trading/project/ant/trading.ipr

The project is set to use relative paths.

The roots in the project is:
c:/cvs.local/its.dev