This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
In Git when I merge and there is a merge conflict. If I try to resolve the conflict from the commandline using --theirs option NetBeans prevents this. The editor seems to be locking the file. If I colse the file in the editor the command works fine. Here are the steps to reproduce: 1. Create a merge conflict 2. Open the conflicting file in the NetBeans editor. 3. Try use --theirs option to resolve the conflict. 4. Unlink of file failed message will occur. This issues doesn't occur if the file is not open in the NetBeans editor. $ git merge myBranch Auto-merging mavenproject1/pom.xml CONFLICT (content): Merge conflict in mavenproject1/pom.xml Automatic merge failed; fix conflicts and then commit the result. $ git checkout --theirs mavenproject1/pom.xml Unlink of file 'mavenproject1/pom.xml' failed. Should I try again? (y/n)
does this happen for all files (also for source files)? Or just for pom.xml?
Just checked. It doesn't happen for .java and .xml files. So it looks like it is purely a Maven pom.xml issue.
a merge conflict effectively modifies the pom file and the project starts reloading. At that time, it's likely that the maven codebase is touching the file (and likely failing fast) the only suspicious code in pom files editor is POMDataEditor.messageName() that reads the file as dom tree to extract the artifactId for the title.
http://hg.netbeans.org/core-main/rev/b1d3b17ef682 reduces the number of reads of the pom.xml file. however for deeper evaluation, I need to try on a windows machine first.
I cannot reproduce locally on my win7 notebook. Even without the change I've committed yesterday. what I did. 1. created a git repository with one project 2. created 2 clones, modified each clone' pom.xml (different artifactId) 3. pushed one of the clone changes to parent. 4. in the IDE pulled changes, allowed the IDE to merge, cancel when it suggested to resolve conflicts. 5. opened the pom.xml file - the conflict was clearly seen in the file. 6. on cmd line tried the git checkout --theirs mavenproject1/pom.xml command which successfully finished. a few notes and questions 1. do you have the navigator open for the pom file as well? (I did and it showed the POM model tab) 2. how fast do you trigger the cmd line commands? does increasing the time in between them solve the issue? 3. is the issue random or 100% percent reproducible for you? 4. does the same thing happen when you trigger pull/merge/resolve from the IDE? 5. after seeing "Unlink of file 'mavenproject1/pom.xml' failed. Should I try again? (y/n)", did you try "y"? how many times? did it work? Please note that netbeans listens on native file changes nowadays and all changes done on cmd line are almost immediately reflected in the IDE. Since the pom.xml file is *the* project file for maven projects, it has to reload itself, the editor has to reload the content, navigators update. Each of these is likely touching the file at some point. There's no clear way of unifying these, as for example maven project reloading happens in 3rd party code. Unfortunately a higher level decision was made a while back that the IDE will respond to IO changed immediately and not when itself gets into foreground only.
I've added reproduce script here: https://gist.github.com/dkirrane/7565273 - The Navigator is open as well. It says Non-parseable POM due to the git conflcit markers - It is 100% reproducible. I've tried on Windows Server 2008 R2 Enterprise also. - It happens for any merge conflict in the pom.xml - After seeing "Unlink of file 'mavenproject1/pom.xml' failed. Should I try again? (y/n)", If selected "y" 20 times and then it worked.
with http://hg.netbeans.org/core-main/rev/b1d3b17ef682 I was not able to reproduce the problem repeatedly. without the patch however, with help of your script I reproduced immediately on an earlier build of netbeans. please test with your setup once the http://hg.netbeans.org/main/rev/b1d3b17ef682 changeset reaches the main repository.
Nice work. I love open source!