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.
[ BUILD # : 200904141401 ] [ JDK VERSION : 1.6.* ] I have renamed a module project, also renaming the directory. The .hg directory isn't there any more (and I can't init mercurial from nb)
Created attachment 80154 [details] messages.log
the implementation behind the rename action creates a new folder, copies only visible project files into it and deletes then all files from the old project folder. Please evaluate.
reassigning to project api
Where was .hg directory? Was it inside project? In NB repository we have .hg directory at root of source tree so rename project should not touch .hg directory IMO.
I can confirm that any dot directory inside project folder is lost when project is renamed and project folder is renamed. Milan is it correct or is it bug?
I must add I tested with Java Application project.
Yes, the .hg directory was in the project dir
The issue is not a regression, not new either. Decreasing to P2. It will be fixed for 6.7. The fix may simply be a warning to the user in the Rename dialog that folders and files not visible in Files view in NetBeans will not be preserved though. It's up to further discussion.
Current behavior is by design. We must discuss what is 'correct' solution of this. There is more aspects: 1.Generally we do not declare any limitation on file/folder names specific to IDE. It means it is not good behavior that file/folder which is considered as 'hidden' by IDE is lost when project is renamed. 2.If given project is inside some VCS ie. it is *subdir* of some VCS tree checkout then simple project folder rename can break it. In such case workaround is to rename project without project folder rename and then perform folder rename using VCS support. Possible solution is to add option to Project Rename dialog if hidden files/folders should be handled or not with warning about possible problem if hidden files are VCS metadata.
I'm in favor of having only big fat warning in the rename/copy/move dialog for 6.7. Because to do this correctly we would need cooperation between project rename/copy/move operations and all kinds of version control systems that have invisible folders (beginning with '.') with metadata (CVS, SVN, Hg, ...). Currently we do not have such support in VCS APIs. Suggested warning: "WARNING: If the project is under version control system the operation can destroy metadata needed by the version control system." Reassigning to olangr to verify/provide warning message. Please reassign back.
The message seems OK to me, but I'm not a native speaker. However, it will not fix the problem, it will decrease it's severity and put some of the responsibility from us to the end user. I'd say that the message will decrease priority (possibly to P3), but the problem persists (transforms into "it is not possible to rename a version controlled project").
With a lack of a better solution for 6.7, let's show the warning.
Warning message implemented: http://hg.netbeans.org/core-main/rev/4a23a61e4459 Decreasing priority to P3.
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/4a23a61e4459 User: Milan Kubec <mkubec@netbeans.org> Log: #162718: providing warning message about renaming CVS controlled project
*** Issue 163793 has been marked as a duplicate of this issue. ***
Decreasing it to P3 doesn't seem to be appropriate.. As Renaming a project, means just* rename.. and user is not expected to be aware copy/delete scenario. I've tried looking at other IDE(s) and they JUST rename the folder instead of re-creating a new folder. Current behavior of Netbeans is not as per the user-experience guide lines. but also error-prone as any thing might happen while this big 'copy' process is going on.. for e.g. the process is crashed(or killed), developer is left with UNUSABLE folder. A better solution would be to JUST rename the existing folder. as it is cleaner and does NOT require integration between projects and VCS modules as the vcs-specific files are left intact. If the mentioned solution is not possible, a better name for the operation should be used instead of 'rename'. Raising the priority to P2 as this impacts DATA-INTEGRITY.
We are aware of the problem and that's the reason for the big fat warning on the dialogs to warn users that some data may be destroyed. On the other side the statement about "... does NOT require integration between projects and VCS modules ..." is not right either. If the project is versioned under VCS that we support we need to take correct action depending on the operation (move/copy/rename; all these operations are implemented together). Currently we support number of VCS, e.g. CVS, SVN, Hg and some others via modules on Autoupdate. Some of those VCS even do not support those operations (e.g. CVS), some of them yes. To implement those operations correctly we need to combine filesystem calls as well as VCS calls depending on VCS. Given the fact that NetBeans 6.7 is currently in stage Beta, there is no time do implement correct fix for the problem. For 6.7 there will be only the warning. The current functionality is in IDE probably from some 4.x release. The functionality works without problems for non-versioned projects.
*** Issue 166692 has been marked as a duplicate of this issue. ***
And here is the way how to rename a project that is also root of hg repository: 1) Comit all changes to repository 2) *Outside of IDE* copy .hg folder and possible other .hg files (e.g. .hgignore) to backup location 3) Rename the project in IDE (.hg metadata are deleted) 4) Close IDE 5) Copy all .hg metadata (from point 2) back to the project 6) Start IDE I might try to come up with better warning message on the dialog.
I'd suggest creating two messages: the first for Rename and Move operations, the second for the Copy operation: *Rename, Move:* WARNING: This operation will not copy over hidden files. If this project is under version control, this operation can delete the metadata required by the version control system you are using. *Copy:* WARNING: This operation will not copy over hidden files. If this project is under version control, the new project copy will not include the metadata required by the version control system you are using.
Unfortunatelly, Copy dialog and Move dialog uses the same UI, so currently it's not possible to use different message. I've used "Rename, Move" message also for "Copy".
*** Bug 135882 has been marked as a duplicate of this bug. ***
NetBeans already has the ability to copy/rename folders which are under version control, performing all of the appropriate VCS commands, so I don't see how applying this to a project's folder would be any different, besides updating all the paths and such in the project metadata. One thing I'd like to mention is that in bug 142616 (resolved as a dupe of bug 135882), the Project folder itself was not under version control. No .svn directory existed in the Project folder or its parent directory, but it did exist in a subdirectory. Even in this case, where a simple rename of the Project folder or copying of its entire contents would have worked fine, NetBeans' rename operation destroyed the VCS metadata. Do these operations perform a recursive search through the folder hierarchy for version-controlled data when performing a move/rename/copy? If so, why? Moving, renaming, and copying a non-version-controlled folder with version-controlled contents are safe operations. It seems to me that you could use the same logic that you do on normal folders and apply it to Project folders: if it's not under version control, perform a copy/rename normally through the file system, but if it is under version control, perform the VCS commands as well. There must be some reason why this isn't already how it's done.
Perversely, the implementation of move (incl. "rename" when "also rename project folder" checked) was actually creating a new directory, then moving each child of the original project one by one. Simplifying this to just moving the original project dir fixes the problem for rename w/ rename folder. Bug #180116 prevents it from working for the case of move (i.e. to a different parent folder).
Created attachment 93737 [details] Proposed patch
Created attachment 94095 [details] Updated patch
core-main #16efe090ec1e
Integrated into 'main-golden', will be available in build *201002170200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/16efe090ec1e User: Jesse Glick <jglick@netbeans.org> Log: Issue #162718: fix project folder rename/move to preserve exact contents.
*** Bug 81258 has been marked as a duplicate of this bug. ***
*** Bug 81941 has been marked as a duplicate of this bug. ***
Integrated into 'main-golden', will be available in build *201102160501* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/ad1957b48169 User: Jesse Glick <jglick@netbeans.org> Log: Extending #162718 and related fixes to rename-with-folder of Maven projects.