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 wasn't sure if this should be against vcscore instead (as I imagine it would mean changes to the suite of links from vcs into the netbeans system).} Subversion (SVN) currently only has basic support in NetBeans (the SVN profile - personally, I think its not even up to the level of support that CVS has). There are many IDEs with better SVN support than NB has. Subversion is modelled as a 'better version of CVS' but does a number of things differently than CVS. From my (not so good) memory of CVS, CVS doesn't have a built in "move" concept - you have to delete then add the new file. The way that Subversion works (integrated moves, renames, copies etc.) has IMHO great potential to integrate more highly into an IDE than other version control systems. The key things I can think of that would really make a difference are as follows: 1. Integrated move/copy support: A move of a versioned file (to a likewise versioned directory) should call the subversion move command. A copy could perhaps prompt the user whether the copy should be added? 2. Integrated refactoring support: I should have made this number 1 - it tempers the power of both subversion and netbeans, specifically with renaming/moving files. Current technique is to refactor, then work out what changed, manually move the files back using OS commands, then perform a subversion move.. Ughh. The ideal functionality would be for the refactorings (again when operating against one versioned repository) to be applied using subversion moves. 3. subversion statuses showing (can't remember if the profile does this) 4. fully integrated repository diffing, merging 5. Can't think of anything else right now .... there's bound to be more...
I should add that currently it is impossible to invoke Subversion (or even CVS) operations on a package from the Project tab. This should be added.
I would say: Subversion 1.1 support.
Here are the things that I want to work on: Short term 1. Fix misc bugs 2. Graphical Diff support 3. Graphical Merge support Long term 1. Drag and Drop 2. Versioning tab (or similar) support Gili: move/copy support - this has to wait until the netbeans api has stabilized. I checked with Martin about this and it doesn't look like it's trivial to implement. refactoring - this one has major implications but of course I see the benefit. status indicators - yes the current profile has this fully integrated diff/merge - initial support will be to use Netbeans existing diff and merge support. The Netbeans diff and merge support is not quite on the level of say eclipse's but we can petition to improve that api separately Thomas: The current profile fully supports subversion 1.1. Is there a command or option that is missing?
Yes, it works with Subversion 1.1. Just wanted to suggest to change the Summary for this issue.
Status indicators: Gili, I understand now that you wanted status indicator Icons, not just the text that's displayed next to the file. I didn't understand how this worked until recently but the next version of the profile supports the basic icons like check mark for up-to-date, + for modified/added, c for conflict, and - for deleted. It's release is dependent on http://www.netbeans.org/issues/show_bug.cgi?id=52081 or at least a temporary fix in the profile to avoid that issue (that's what I'm leaning towards since 4.0 is just around the corner).
Basic status indicators are supported by the subversion module in cvs. A work around for: http://www.netbeans.org/issues/show_bug.cgi?id=52081 Has been implemented so that the next release isn't delayed (some variables are defaulted to appropriate values instead of taking global values from the versioned directory setup dialog) Please change the Summary to read: "Fully integrated Subversion 1.1 support in NetBeans" instead of 1.0 if that is what you intended. I know that I will not be supporting subversion < 1.1 with this profile although it may work with 1.0 for the most part.
Ideally we should integrate JavaSVN into Netbeans. See http://www.theserverside.com/news/thread.tss?thread_id=37406 for more information.
*** Issue 53832 has been marked as a duplicate of this issue. ***
*** Issue 59610 has been marked as a duplicate of this issue. ***
I'm just looking for an update on the progress of this issue. Has there been any progress in making the SVN module as usable as the CVS one is in 5.0 final? Last time I checked the interface was completely different (SVN was much worse).
> refactoring - this one has major implications but of course I see the > benefit. *Benefit* !? I would say that was an understatement. If you use subversion for your project it completely undermines all refactoring functionality netbeans has to offer. I predominantly use subversion, and most open-source libraries I work against are also subversion based. (Why netbeans code hasn't been migrated over I just don't know, especially the troubles the size of the netbeans codebase puts on the cvs server. Subversion is part of collab.net as well.) The work around is *painful*. If Eclipse supports this feature then I would definitely switch if I wasn't such a long time netbeans fan and familar with the code underneath, because this is a *major period of time wasted* for the user that netbeans could be saving. It could quite likely be hours per week from my experience. So inrelation to user productivity I would be classifying this point alone as critical (P2). Graphical diffs and merges are but a drop in the ocean in comparison.
I second the motion. A refactor-aware Subversion module is definately a P2 for me. Currently every time I rename or move a file I have to manually update Subversion myself. Consider: - I move package1.A into package2.A - I then have to go into Explorer using TortoiseSVN, into package2.A, move the file back into package1.A then tell TortoiseSVN to "move" the file into package2.A And I have to do this once per file. If I rename a package I have to repeat this process for every single file in the package. It is *extremely* painful.
Get attention of the new subversion module developers.
New Netbeans Subversion Support is coming soon. Not only refactoring will be improved. ;)
I'm sorry, but search on NetBeans for subversion gives a link to this issue, but not to the demo by Roman Strobl, so it's worth to put it here: http://www.netbeans.org/download/flash/subversion/subversion.html
P.S. I miss an ability to checkout by certain date. Where should I report that?
For VCS generic subversion support -> component: vcsgeneric, subcomponent: experimental prodiles For new upcoming subversion support -> component: subversion http://subversion.netbeans.org/
I don't understand, why does the upcoming Subversion integration depend upon a native SVN installation instead of simply using JavaSVN?
Java 1.5.0x doesn't allow to change many attributes of files/folders. And in case of windows platform there is no way in pure java how to create hidden folders. (svn - metadata) and many others.
With very little effort, you could easily implement File.setHidden(boolean) in a cross-platform manner across UNIX and Windows (granted this isn't included in Java5). Under UNIX you'd translate setHidden() to renameTo() and add/remove a prefix of '.' -- this would work using pure Java code -- then for Windows you'd use a tiny JNI interface to change the file attribute to hidden. I personally prefer this approach to relying on users to install the Subversion client on their own. And in future releases (Mustang?) hopefully we can have a pure-Java version of this. On a related note, I wonder how JavaSVN works. They claim to be "pure Java" yet I wonder how they get around the above limitations. It is possible that under Windows, SVN does not care whether the files are hidden or not and under UNIX they simply use renameTo(). In such a case they are probably "pure Java" while implementing the SVN protocol. Any ideas?
JavaSVN should be a real priority. To most users, and in comparison to Eclipse, it seems a bit ridiculous that a platform-independent IDE needs to have extra software installed for something as basic as SVN support. However, until that is the case, there should *really* be an option to set the PATH within NetBeans. I have svn installed on my Mac in /usr/local/bin (version 1.3.1, which is supposed to be good), but NB doesn't find it. subversion.netbeans.org says that the above is indeed the location it will look in on Unix-like systems. (And I think Mac OS is as Unix-like as it can get.) So since it doesn't work, I'd really like the opportunity to set the path explicitly. Maybe it's there, but I could't find it even in the advanced Prefs. Also: there should be an entry on setting the PATH for Subversion in the NetBeans help system.
Have you tried to use switch for svn executable "-J-Dsubversion.path=/path/to/subversion/bin" for example: -J-Dsubversion.path="C:\Program Files\Subversion\bin" - path contains white spaces therefore quotes are necessary.
This issue became obsolete, we have subversion support (1.3 and later) in NetBeans 6.0.