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.
Summary: | subversion causes copy to another location failure | ||
---|---|---|---|
Product: | versioncontrol | Reporter: | nbphpuser <nbphpuser> |
Component: | Subversion | Assignee: | issues@versioncontrol <issues> |
Status: | RESOLVED DUPLICATE | ||
Severity: | blocker | ||
Priority: | P2 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
nbphpuser
2009-06-09 12:51:04 UTC
Can you delete the file Y:\project\trunk\libs\User.class.php in IDE? I mean not with php support but e.g. in files view? Could you try and check the message log for any related mesasges? "IDE? I mean not with php support but e.g. in files view?" In files view, you can see only source folder not destination. However I _can_ delete files in Windows explorer. Destination folder is on samba share and has 777 rights on all files except .svn folders. It looks like IDE tries to copy file to destination folder, but subversion component also tries to read .svn in destination folder, which is not desired. We want to change the file there, not an .svn entry associated with it. There are also some files which are not currently under svn, but it fails either for them for the same reason. "svn: Can't open file 'Y:\project\trunk\libs" Because the source area and the target area are both versioned by subversion, IDE lets subversion to handle the file
copying. I do understand that you might not want this behavior but there is no way the subversion module can decide if
the target area shoul be treated as unversioned. The svn module intercepts a file-system delete event, recognizes the
to-be-deleted file as versioned and thus tries to remove it with 'svn delete'.
> svn: Error processing command 'upgrade-format' in 'Y:\project\trunk\libs'
You are probably using subversion in version 1.6 and the working copy in 'Y:\project\trunk\libs' seems to be in an older
format (I presume 1.5) and the svn client is trying to upgrade that working copy to 1.6, which is obviously not allowed
by file-system rights.
Are you allowed to operate with subversion metadata in 'Y:\project\trunk\libs' with 1.5 client?
Or do you just simply want to copy, delete or create files on file-system level there, knowing that e.g. deleting a file
leaves the subversion metadata flawed (the metadata see the deleted file as MISSING, not as REMOVED)?
If so, than there's currently no support for that, we'll discuss it in the team and I'll let you know. I think it could
be possible to start Netbeans with a certain command-line switch which could direct the subversion module to interpret
certain file-system areas as not managed.
> Are you allowed to operate with subversion metadata in 'Y:\project\trunk\libs' with 1.5 client?
Meaning are you able to invoke svn commands (add, remove, copy, etc.) with a 1.5 client?
"Because the source area and the target area are both versioned by subversion, IDE lets subversion to handle the file copying. I do understand that you might not want this behavior but there is no way the subversion module can decide if the target area shoul be treated as unversioned." Why would one want that? I mean, the main purpose of copying files to another folder is copy files and not .svn entries. At least I wouldn't expect that behavior. Sure, my situation is not typical. Anyway, may be a flag in project settings for that, so we could decide if IDE should handle .svn? I think, I should add some details to my situation. I do checkout in local directory on windows, but not the hole project, which is very big, because NB performs not very well on my machine. After NB initially copied files to destination directory, I do full checkout there (1.5 client on linux). In that way, I have small fast project on local drive and only some changed files would be copied to Samba share. If I need update on Samba, I do checkout there via ssh (not with windows svn client) Hi, after a discussion in the team, i think i have a solution. To force the versioning system to leave some folders unmanaged, you have to: 1) Open (or create if it does not exist) a text file ~/.netbeans/67rc2/config/Preferences/org/netbeans/modules/versioning.properties 2) add a new line: unversionedFolders=Y:\project\trunk\libs 3) save the file and restart IDE This directive should strip that folder (and all subfolders) out of the versioning management Let me know if it helps. See also http://www.netbeans.org/issues/show_bug.cgi?id=105161 - this is probably it's duplicate It looks good! <happiness /> At least today I didn't have any problems Thank you very much! You're welcome. I'm making this a duplicate of #105161 *** This issue has been marked as a duplicate of 105161 *** Have a look at issue #172139 for more information. Thanks. |