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.
if you rename a subversion controlled project and choose to rename the project folder as well, it would be nice to offer to rename (move) the subversion repository folder as well.
marking as a defect, since committing the old folder will delete all of the contents from version control.
1.) "committing the old folder will delete all of the contents from version control" - committing the old folder opens in the first place the commit dialog which clearly shows that the files will be deleted. Hitting the commit button in case they shouldn't be deleted definitely isn't the right thing the user should do. ENHANCEMENT. 2.) reassigning to version control as this isn't something we should discuss only in regard to svn. 3.) not sure this can be backed up by a simple svn cmd (sequence) - i vote for a wontfix
yup, i see your point. the more i think of it, the less i see it as a project issue. how about something more generic--if any (top level) vcs controlled file/folder is renamed, it offers to add the new file/folder to vcs. if yes, it does a rename instead, to keep the vcs history. this will be more in line with how items within a vcs controlled folder work when they are renamed.
looking on it from a users perspective i agree that when the rename or copy action gets called for a project one would also expect that the change will be somehow reflected in the relevant vcs. The thing is that it isn't always that simple in the means of the needed vcs commands and the available infrastructure as well. Let's see if we can do something in the future...
*** Issue 142616 has been marked as a duplicate of this issue. ***
If an operation (such as move or rename) is performed on a non-version-controlled parent directory which contains version-controlled files, that operation should not trigger any version-control operations. Currently it does, and that causes problems. In this case, the operation should affect only the local file system, copying the working copy and all relevant versioning metadata from one location to another without modifying any of it. The issue which was just marked as a duplicate is about this case specifically. I don't think it's a true duplicate, but it is related to how NetBeans handles renaming and version-controlled files.
agree, 142616 isn't a duplicate
bump...
Looks like this was never dealt with... This is still an issue, and when dealing with large projects, a rename in NB will cause a minor nightmare, either in editing the project files to restore the old name and moving the directory by hand, or having to re-add the newly named directory and lose all of the svn history. It appears that NB renames the directory by hand and then issues the equivalent of 'svn rm -R' on the old folder. It should use (the equivalent of) 'svn rename'.