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.
Svn commit when you have many files to commit is very slow. E.g. You have to commit to your svn a javascript library like dojo that has lots o small files (i don't like committing third part library to my project but sometimes you have to commit them, for instance i have a continuos integration tool that is bind to an svn repository ) At first commit of the directory containg many files, the IDE hangs on "Preparing files for commit", with no output for the user (it can output current file at least, to avoid user closes the IDE thinking that is deadlocked), for dojo under an intel i7 SSD linux machine it hangs for over 10 minutes. It's strange if it uses the svn command line executable that i've installed on the linux machine , because if from a shell i do: svn add dojo/ it requires just 45-60 seconds. So i think netbeans is doing recursive adds/commit on single files or some preprocessing in java that can be surely avoided in commit phase (because if i commit from shell the IDE reads the svn files and update his versioning state correctly, so preprocessing can be successful skipped in this way like i do now)?
Attach a profiler snapshot so we can identify what's taking so long while committing your files. http://wiki.netbeans.org/FitnessViaPartnership
Created attachment 116315 [details] Netbeans self profile while "Preparing Commit" A normal pre-commit of all the java web project (from root directory). I stopped it before end. Adding new dirs takes longer. Normally if i select just single changed files with ctrl+click the IDE i can commit in few seconds maybe is also ntfs that i mount from windows partition via fuse that slows the thing down (ntfs is very slow with many little files)
Try running the IDE with -J-Dnetbeans.subversion.commit.deepStatusRefresh=false With this switch, commit will skip the preparation phase and will list files directly from the cache. However you must be sure that all the files are correctly in sync in the IDE with the ones on disk. If you for example do an external commit (not in the IDE), the files will remain as modified in the IDE and the commit dialog will tend to list them. Alternatively, you can run commit from the Versioning or Diff view. Invoking the commit from here will skip the phase automatically.
Thank you very much for the tips, using these options is perfect for my need and works like a charm :) Anyway my excessive slowness was due to an hardware problem i just discovered on my SSD. Sorry to have raised this report. Best, Stefano
(In reply to comment #4) > Thank you very much for the tips, using these options is perfect for my need > and works like a charm :) > > Anyway my excessive slowness was due to an hardware problem i just discovered > on my SSD. Sorry to have raised this report. > > Best, > Stefano Hi Stefano, Sorry for commenting on a resolved issue but I wanted to know what hardware problems you had and if you fixed them. I have an SSD set up as a Cache drive using Intel SRT and I'm wondering if there is a connection to some slowness bugs that I'm getting.
-J-Dnetbeans.subversion.commit.deepStatusRefresh=false doesn't help, problem still exist in netbeans 8.2 with idk 1.8.0_65
(In reply to mcheung63 from comment #6) > -J-Dnetbeans.subversion.commit.deepStatusRefresh=false doesn't help, problem > still exist in netbeans 8.2 with idk 1.8.0_65 Please do not reopen that old issues, file a new one, attach the full messages log and a profiler snapshot there demonstrating the slow prep phase. http://wiki.netbeans.org/FaqLogMessagesFile http://wiki.netbeans.org/FaqProfileMeNow