Idea's merge tool instead of CVS conflicts?
Now that Idea has such a great merge tool:
Is there any way to get the merge tool when (i.e. before) a CVS update produces a conflict? (Rather than having the source itself obfuscated with CVS conflict markers and then comparing the already poluted file with the latest CVS version.)
I understand that the merge tool is used when merging CVS branches, but when I stay on the same branch no matter if I choose "Don't merge" or "Merge with HEAD" I always just get CVS conflict markers in the source.
请先登录再写评论。
On Fri, 23 Jan 2004 18:17:57 +0000, Stephen Kelvin wrote:
I would love this - I often get conflicts happening in the .ipr or .iml
files ( often its usually just white space, for some reason two machines
write out differently ), and IDEA just barfs when it reloads the project.
Why do you put the ipr and iml files under version control ? Shouldn't these file be rather user specific and therefore excluded from vcs ?
Thomas Gülden
Munich, Germany
No, ideally both project and module descriptions should be shareable via CVS. If you have a complex project it saves a lot of time if the very same project isn't configured again and again on each developer's machine.
Only the iws (workspace) files should probably not be shared.
That said: Idea still has some severe bugs, that prevent (or at least hinder) sharing of ipr/iml files.
On Mon, 26 Jan 2004 07:48:35 +0000, Thomas G?lden wrote:
Mmmm, not the project/modules no, at least I dont think so. When I check
out the project to a different machine, it's nice to know I don't have to
go and create modules again each time something changes.
Well, you don't need to deal with the CVS conflicts manually. After updating, just right-click on the files where conflicts ocurred (the ones marked red in the CVS update messega) and choose 'Merge'. That will launch the merge tool for you :)
On Mon, 26 Jan 2004 10:14:21 +0000, Marcus Brito wrote:
This doesn't help when there in the project. IDEA prompts you "project
files have been modified, reload?", theres no visual mention of "hey,
project files were modified, and are now broken", so the reload barfs
Thanks a lot! That deserves a "tip of the day"!
I think that option should also be more prominently displayed.
Agreed. A project doesn't feel complete without its config files under source control. For various reasons, we've had to move our whole team to new locations a couple of times over the last month, and having the whole project in cvs allowed us to be very mobile.
We've only encountered two hinderances:
1. If the .ipr or .iml needs merging, we do this through commandline cvs; i.e., update through IDEA, close project, merge manually. Turns out a concurrent change to either of these files if very rare - i think we've only had to do this twice.
2. We usually keep the 'Reformat' option checked during a commit, but IDEA removes empty space before the end of an empty tag (' />') when reformating xml files, whereas it saves its .ipr and .iml files with this extra space. This means that if you reformat either of these files, you'll introduce changes in almost every line. To get around this, we commit any changes to these files independently with Reformat turned off.
cheers, lasitha.
We have large projects and our way of keeping all developer's project files in sync is to create the project files (.ipr, .iml, .iws). Once done and all libraries, modules, and such are configured:
1. Close IDEA
2. Copy all project and module files
3. Suffix the copies with .template
4. Check the .template files into CVS
When the time comes to work on the project, remove the .template suffix from the end of all files and load the project. The project files without the suffix are kept in your own sandbox, and the master copies are stored in CVS. If a change need to be made to the master, then when the next checkout happens, the devloper should see the file update, and should overwrite their sandbox project files with the new ones pulled from CVS.
Just a thought, we have found that it works well.
Regards,
Eric
Hm. Did you ever check out your project to another path?
1. Idea always stores absolute references in the project (ipr) file. Only module files (iml) have the option to store paths relative. The only workaround is to have a "Path Variable" (see IDE settings) defined to point to your project root.
2. If you try to open a project using path variables without having those very same path variables defined, you'll get no warning at all - but the project files are CORRUPTED. It doesn't even help to close the project, define the variables and open it again. You have to get a clean copy of the iml/ipr files, first.
First i have to admit, we are new at this and have gone only a few weeks with the scheme i describe below. I suspect you speak from a far more experienced position.
Yes. In fact, we work in an XP team, so no machine belongs to any one developer; each box has multiple checkouts of the same project, eg:
C:\users\me\project
C:\users\mypair\project
(We need to do this so that different developers can maintain different values in their CVS/Root files).
Not true in our case; perhaps you and i have structured our projects differently? The only absolute references i see in my .ipr are to my global libraries - these are placed in the same directory (C:\java\) on every machine.
Ah, maybe this is the kicker: we don't have projects that depend on 'external' modules. For example, suppose i have:
- ProjectUtils (w/ ModuleUtils)
- ProjectA (w/ ModuleX and ModuleY)
ModuleX and ModuleY are only used by ProjectA, so they exist in a sub-directory of ProjectA. ProjectA depends on ProjectUtils, but as a global library, not a module dependency. ProjectUtils is built separately by ant.
With this setup, the .ipr never refers to anything outside its topmost directory (except global libraries which are in a fixed location); hence no absolute paths. If i want to work on both ProjectA and ProjectUtils in the same workspace, then i need to create a .ipr in a directory above both and checkout both projects.
I suspect we're not using IDEA's module capabilities to their fullest, and are filling in the gaps with ant. The fact that we only have global libraries and NO module or project libraries has been a question i've been meaning to research :)
Any thoughts appreciated.
cheers.
>> 1. Idea always stores absolute references in the project (ipr) file.
>Not true in our case; perhaps you and i have structured our projects differently? The only absolute references i see in my .ipr are to my global libraries - these are placed in the same directory (C:\java\) on every machine.
I am using project level libraries which are located beneath a sibling directory to the project directory, i.e. they are not beneath the project dir, but still reachable via a relative path.
The same goes for the many module file I have checked in. They are in a directory "idea" in each module's content root where the content root isn't beneath the project root.
I see how your project structure makes the 'no relative paths in the .ipr' restriction annoying. I suppose you can at least checkin the .iml's ..?
Out of curiosity, what kinds of things do find useful as project or module libraries? I find myself using global libraries exclusively - all shared through cvs and checked out to a fixed location on every developer machine. This has been useful as a central 'repository' of libraries and by also sharing the IDEA/config/options/applicationLibraries.xml file we essentially have no redundant library definitions.
I had hoped for that project level libraries are automatically shared between developers.
One of our problems is that some developers are on Linux and some on Windows, so it's just impossible to use the same absolute path everywhere (Drive:\... vs. /rootdir).
Unfortunately we currently have to use path variables to be able to share project libraries (as relative paths do not work with our setup).
Off course then using path variables would also allow us to share global libraries.
A major problem is that if you forget to set these path variables prior to opening the project, Idea issues no warning, local project files get corrupted and you have to get a clean copy from CVS, set the path variables and only then you're able to open the project again.