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 am unable to connect to an alternate port on the password server. I tried specifying it in the server input dialog as hbrdb.xx.xx.com:2402 and also in the repository input dialog as 2402/usr/project/cvsadmin/cvsroot The following cvsroot works when I try it from cvs command line :pserver:lloyd@hbrdb.xx.xx.com:2402/usr/project/cvsadmin/cvsrep
specifying other port than 2401 is not possible in 3.2 in the upcoming version 3.3 it is possible. However not during the mounting wizard. You have to mount with standard port and then set an advanced property of the filesystem to the port you want. You can login to that CVSROOT from within the Versioning/Cvs Password manager dialog. in 3.2 you can still connect to another port by using the command line client and setting the CVSPORT enviroment variable (please see cvs documentation for details I don't have that at hand right now)
I think it's fixed in 3.3. The specification of the port is not included in the filesystem mounting wizard, since it's not very frequent to have another port then 2401. (One needs to recompile the cvs sources to be able to start the non-standard port, right?) However even when this workflow is not supported in the wizard, it's possible to mount a filesystem, by loging in to the server via the menu item Versioning/CVS PAssword Manager. then mount the working directory of your choice (probably in offline mode) Then change the offline mode and server port properties after mounting.. (setting the properties can be done for 1 or more filesystems at once.. So I'm closing the bug as fixed. Please check in the 3.3 beta or final release and reopen the bug if it doesn't work.
I agree with Milos. I also consider this as fixed since there is a way around it :-) If you don't think so, reopen the bug with description what's wrong. Verified in development build #200110250100 of NetBeans 3.3.
Jirka, do you think it would be possible to install a cvs server on non-standard port someone on one of the QA machines? So that we could really test if it works.. It theoretically should but I haven't checked (I didn't have time enough to play with setup of such a server)
I hope so, however not before next Tuesday because of other important issues.
*** Issue 17090 has been marked as a duplicate of this issue. ***
I would request that the status be changed to defered(I understand nobody has time now) instead of fixed. What I see is a workaround that is makes the software 'unfirendly' to use and thereby losing it's appeal.
Dan Mladek created a TASK for this purpose.. #17101. There's a lot of places in the IDE that are made to be friendly to the majority of the user scenarios. I doubt we can make every single situation user-friendly. Including the port etc. in the wizard. We'll make it less userfriendly to people that have no idea they need to know anything about the ports the server runs on. It's always a matter decision. I freely admit that the decision was partly influenced by the fact that we don't want to touch the wizard, it's workflow and all the logic of the code there so close before the release.. 1. How often do you mount/unmount a filesystem? why? 2. Why do you have the server on non-standard port?
reopening
*** This issue has been marked as a duplicate of 17101 ***
How often do we mount/unmount file systems? No too often. But repositories do tend to get moved around between prototype and beta phase. Why we use non-standard port? We have about 12 repositories and they do not all fit onto single inetd.conf line. Infact we have not been able to get more than one repository on a single inetd.conf line to work. Again, I donot wish to impact the current release - just that you defer it until maybe next release. As for people having to know ports - there is always the concept of default port. WinCVS does this rather nicely. We are currently using WinCVS to manage our repositories.
just a curious question. As you spoke about moving from prototype to beta etc.. why don't you use the branching feature of cvs? That's what branches are for IMHO. you could have a branch for each release, beta, prototype within one repository. having 12 repositories seems to me like an organizational overhead that also causes you to loose source version history between protory/beta/release.. And yes, it's currently postponed to next release..
well, I'd rather see this bug as duplicate of issue #13901 (but I'm going to leave it without change...necesseary to reopne the bug,etc.). But there've been fired another 2 issues; say rather TASKs: * issue #17101 * issue #17102 for the complete implementation in all CVS modules
prototype are 'play' repositories setup by developers. They then move the code to actual repositories when they are 'ready' to start project specific coding. It's just a culture - no technical reason behind it. But it does reduce the time for identifying dead/unused modules. Also the developers tend to use the repositories as 'backup' and reversible 'checkpoints' which do not contribute much towards revision history from a functional-change/bug-fix perspective. Once in actual repositories then branching is used. Also once in production the original developers loose 'regular' access to the repositories as it is handedover to the maintenance department(at which time the repository(host/port only) moves again).
Resolved for 3.4.x or earlier, no new info since then -> closing.