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.
I have a four compile configuration for a project. Adding and removing files is very common. Sometimes, makefiles do not get up to date, and are commited to svn in that state. The result is that other party can not compile the code. E.g. when I change project properties, the makefiles are recreated. Now, if I try to commit to svn, the svn will report files as deleted, although the makefiles are recreated and they exist on a file system, and upono commit it will delete them in a svn repository.
I can reproduce the situation the following way: 1) create any sample project 2) add new file 3) build the project 4) delete and remove the new file from the project using Delete from the files context menu Now the project is marked 'dirty' but hasn't been saved yet. Common actions like building, running, and also closing the project will save the project but version control actions won't so I can see if you check in the project before running any other actions would commit inconsistent metadata files. Work- around is to for instance build the project first. Perhaps the project should be save every time a file has been added or deleted.
I will try to provide you a more detailed description of how to reproduce. For now, I am sending you only attachement with a part of a screenshot. The makefiles are marked deleted after changing project properties, section Linker.
Created attachment 74151 [details] First SS
Created attachment 74152 [details] Second SS
As you may see on second screenshot, the project is saved.
Sorry, you forget to set right mime type for second picture.
Created attachment 74179 [details] Second SS
Fixed. Now making sure all sharable files are saved before sharebility query.
Integrated into 'main-golden', will be available in build *200904251401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/924f7ce118c7 User: Thomas Preisler <thp@netbeans.org> Log: #153504 Makefiles goes to svn in not up to date state
It seems fix wrong because created second instance of make project that reads already loaded configuration xml. See attachment. Steps: Start IDE wit opened project. See two instances of ConfigurationDescriptorProvider: @1ccaf14 and @c7352a Invoke project context menu. See exception about reading configuration xml
Created attachment 81331 [details] log
revert modification: http://hg.netbeans.org/cnd-main/rev/f5e758b1af20
Integrated into 'main-golden', will be available in build *200905010201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/f5e758b1af20 User: Alexander Simon <alexvsimon@netbeans.org> Log: revert modifications for IZ#153504:Makefiles goes to svn in not up to date state
Refined the code a bit: now won't check if project hasn't bee read. We don't need the information at that point so it is OK to skip it here. Will ask Alexander S. for review.
Integrated into 'main-golden', will be available in build *201004180201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/96e7254e312d User: Thomas Preisler <thp@netbeans.org> Log: #153504 - Makefiles goes to svn in not up to date state
Fix is OK.
Created attachment 103657 [details] thread dump
Unfortunately fix does not work in case folder nbproject/private is empty. See infinite loop in attached thread dump. I will roll back changes.
Created attachment 103658 [details] call "Project Properties" window on the attached project and press OK ==> infinite loop
Integrated into 'main-golden', will be available in build *201012080001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/7a912ffc5827 User: Alexander Simon <alexvsimon@netbeans.org> Log: roll back changes for Bug #153504 Makefiles goes to svn in not up to date state
Looks like Alexander is making most of the changes related to the issue. So it seems logical to have it assigned to him.
Reassign to evaluation. VCS is responsible for getting files up-to-date.
cnd team: i guess makefiles appear as removed/deleted because you generate them using either an external tool or delete and recreate them through java.io.File instead of using FileObjects. If you used FOs (or at least just overwrite the files instead of delete/create them), subversion would obtain proper FS events, react accordingly and the makefiles would appear correctly as modified. *** This bug has been marked as a duplicate of bug 194998 ***
(In reply to comment #23) > cnd team: i guess makefiles appear as removed/deleted because you generate them > using either an external tool or delete and recreate them through java.io.File > instead of using FileObjects. If you used FOs (or at least just overwrite the > files instead of delete/create them), subversion would obtain proper FS events, > react accordingly and the makefiles would appear correctly as modified. Problem is in saving files before VCS operations. For example command "Mercurial->Status" saves all unsaved changes in opened editors. CND projects have several files that must be saved (regenerated) before VCS operations. So VCS should provide interface for saving changes.
Hi Simon, > Problem is in saving files before VCS operations. 1.) this issue is a bit confusing. The original report was made about files being deleted by a commit, but the last comment is about files not being saved. So for now we will interprete "getting files up-to-date" as "to save all unsaved files". To avoid further misunderstandings it would be great if you could, one more time, provide the steps necessary to reproduce and exactly point out what files aren't saved or are deleted or whatever else it is that's responsible for this issue. > For example command "Mercurial->Status" saves all unsaved changes in opened editors. > CND projects have several files that must be saved (regenerated) before VCS operations. 2.) note that all file relevant vcs actions invoke org.openide.LifecycleManager.getDefault().saveAll() before the actions actual logic is executed. This aplies also to svn > commit, where LM.saveAll() is called before the commit dialog is opened. If there is something else you would like to do at that point, just let us know... > So VCS should provide interface for saving changes. 3.) considering the already mentioned inherent confusion in this issue, we are not sure how we are supposed to understand this statement. Is it interface as in API, or is it interface as in UI, or is it something else you have in mind?
(In reply to comment #25) > 2.) note that all file relevant vcs actions invoke > org.openide.LifecycleManager.getDefault().saveAll() before the actions actual > logic is executed. This aplies also to svn > commit, where LM.saveAll() is > called before the commit dialog is opened. If there is something else you would > like to do at that point, just let us know... As I understood Alexander's explanation: - some project metadata files are in not saved state => it's preferable to save them before status/commit operations So, one of possible solutions could be: together with LM.saveAll() vcs should call ProjectManager.getDefault().saveAllProjects() (if saveAllProjects forces projects to save it's metadata)
> As I understood Alexander's explanation: > - some project metadata files are in not saved state => it's preferable to save > them before status/commit operations > So, one of possible solutions could be: > together with LM.saveAll() vcs should call > ProjectManager.getDefault().saveAllProjects() could work and easy to do, but sounds like a workaround. LM.saveAll() doesn't seem to be meant to care about touched project metadata and PM.saveProject(Project) makes it clear that it wasn't meant to be used this way. So the question here is if this shouldn't be the responsibility/decision of whoever left the project files in a dirty state in the first place and if there is any reasonable justification to move this responsibility to some another module(s) (vcs, system exit maybe, ...) to cleanup at some, undefined, point later...
(In reply to comment #27) > So the question here is if this shouldn't be the responsibility/decision > of whoever left the project files in a dirty state in the first place and if > there is any reasonable justification to move this responsibility to some > another module(s) (vcs, system exit maybe, ...) to cleanup at some, undefined, > point later... You are right it is C/C++ project responsibility to save dirty meta data. But C/C++ has a specific: - size of C/C++ meta data is much bugger then meta data of Java projects. - C/C++ meta data cannot be saved in EDT without slowness (1Mb in 8 files is ordinary size of meta data). Saving is done under "wait dialog". - C/C++ meta data is changed in much more places then Java meta data. For example: adding/removing files, changing current configuration/tool collection/development host, at run/debug, while debugging. So it is unreal to save meta data after each changing. To solve problem C/C++ need additional "saving hook". The best way is: - allow to register own LM. But LM accept only one instance of service. Another way is: - VCS provides new "saving service". C/C++ implements and register new service in look up. VCS invoke services before VCS actions. Way that can have an resistance from NB API: - VCS call PM.saveAll() Way that does not work due to deadlock: - C/C++ save meta data in sharability query. So C/C++ cannot resolve issue inside C/C++. We need a help from VCS or LM.
> You are right it is C/C++ project responsibility to save dirty meta data. > But C/C++ has a specific: > - size of C/C++ meta data is much bugger then meta data of Java projects. > - C/C++ meta data cannot be saved in EDT without slowness (1Mb in 8 files is > ordinary size of meta data). Saving is done under "wait dialog". > - C/C++ meta data is changed in much more places then Java meta data. For > example: adding/removing files, changing current configuration/tool > collection/development host, at run/debug, while debugging. > So it is unreal to save meta data after each changing. this makes the whole thing a bit more difficult to solve on the vcs side as vcs invokes LM.saveAll() in awt. I agree that this isn't to smartest thing to do but it typically deals with a few source files opened in the editor and didn't cause any known trouble yet. A change like you suggest would need a bigger rewrite. The 7.0 schedule is too tight now do that without a risk. that an operation like removing a file leads to saving about 1mb of data is quite a thing and seems to be the cause of the whole problem. To state that "it is unrealistic to save the metadata when they should be saved" and to expect of everybody who runs into this kind of situation to deal with it on his own doesn't seem to be a realistic approach either. What about other situations, e.g. when the ide is closed or a makefile is to be used from the commandline? Maybe you can figure a few more cases... btw - what about saving the metadata in case of file add/remove only once, after the last filevent in an atomicaction? as to the suggested solutions: > To solve problem C/C++ need additional "saving hook". > The best way is: > - allow to register own LM. But LM accept only one instance of service. > Another way is: > - VCS provides new "saving service". C/C++ implements and register new service > in look up. VCS invoke services before VCS actions. > Way that can have an resistance from NB API: > - VCS call PM.saveAll() not very familiar with LM or PM, but calling PM.saveAllProject seems to be a more pragmatic approach than a new vcs api. cc Jesse, he might have something to add ... but one way or another, the effect is always the same - suddenly we would have to save dirty cnd metadata at some point in vcs. To do that properly asks for a bigger change in the vcs codebase. This all to workaround another problem which should be solved somewhere else. We would prefer not to do that. We don't know if there already is a precedence in nb for such a thing and we do not like to become such a precedence either.
Calling ProjectManager.getDefault().saveAllProjects() before running VCS commands seems like the most reasonable solution. You probably want to do this call off EQ. (Saving modified files off EQ would be preferable too.) I'm not sure how this counts as a "big rewrite" but then I'm not familiar with the VCS codebase. For non-CND projects saveAllProjects will very likely be a no-op, since other project types with savable metadata generally save any modifications very soon after making them - i.e. the client code might update a few properties in quick succession and then call saveProject at the end of the block. (If we could design projectapi from scratch, I would probably have omitted ProjectState and API-level saving altogether; the project could just as easily persist coalesced change events in a background thread after ~100msec automatically, the way e.g. NbPreferences works, perhaps with a flush() method for clients that needed to immediately invoke external tools. This would have reduced the code burden on most API clients, and avoided a few hard-to-reproduce bugs triggered by clients that forgot to save their own changes. The fact that CND projects keep modified metadata in memory indefinitely - because they take so long to do saves - indicates that they have a poorly designed metadata format, which could perhaps be cleaned up in a future release.)
fixed when bug #196378 was fixed http://hg.netbeans.org/releases/rev/9fbfc3d67ad6 + http://hg.netbeans.org/cnd-main/rev/5fb529948602
see #77210 - maybe that could also solve the problem with LM.saveAll() not saving cnd metadata