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.

Bug 16630 - Connection settings are read from working directory instead of relative mount point.
Summary: Connection settings are read from working directory instead of relative mount...
Status: CLOSED FIXED
Alias: None
Product: obsolete
Classification: Unclassified
Component: vcscore (show other bugs)
Version: 3.x
Hardware: PC Windows ME/2000
: P4 blocker (vote)
Assignee: issues@obsolete
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-10-17 10:00 UTC by Jiri Kovalsky
Modified: 2003-07-01 12:58 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jiri Kovalsky 2001-10-17 10:00:21 UTC
Development build #200110170100 of NetBeans 3.3 on Windows 2000 with JDK 1.3.1

Description:
============
If the contents of CVS/Root file in working directory differs from the same file
placed in relative mount point then mounting wizard uses the one in working di-
rectory. I know that this situation is rare but might surprise our users.

Steps to reproduce:
===================
1. Prepare some CVS working directory with at least one folder inside, for exam-
   ple c:\sources\test and change c:\sources\CVS\Root to contain :local:c:\repo
2. c:\sources\test\CVS\Root must contain e.g. :pserver:anoncvs@server:/cvs
3. Now invoke "Versioning|Mount Version Control|CVS" item from the main menu.
4. Setup "c:\sources" as "Working Directory" and push "Next >" button.
5. Click on "test" node to select relative mount point and push "Next >" again.
6. You will see that "Connection Method" panel will select "Local" connection
   method and set "c:\repo" as "Repository".
Comment 1 Milos Kleint 2001-10-17 21:28:34 UTC
the most probably reason for this design is that you can select more
then one relative mountpoints, thus you wouldn't know what to put into
the wizard if these differ. 

I personally consider it pretty bad to have a directory tree coming
from many different servers anyway.
My guess it that it's "as designed".
Comment 2 Jiri Kovalsky 2001-10-18 08:54:59 UTC
The point about multiple relative mountpoints sounds reasonable to me.
Do you Martin agree ?
Comment 3 Martin Entlicher 2001-10-18 12:47:43 UTC
Well, this is a problem. If the user have different server settings
for different relative mount points, they will not be able to mount
correct filesystems, because at least one will have bad configuration.
I still think, that the configuration should be read from the relative
mount point(s) selected. But if these configurations differ, we have
to do anything. These possibilities came to my mind:

1) simply take configuration from the first relative mount point

2) same as 1), but warn the user, that they have different configs and
some mounted filesystem will probably need some customization

3) disable Next> when this situation happens -- this will be confusing
without some visible explanation.

4) Add additional configuration panels, that will configure individual
selected mount points.  -- Too much work, the wizard wil get longer to
proceed, possibility of user confusion.

Anyone has another idea??

Comment 4 Milos Kleint 2001-10-18 17:53:18 UTC
what about to filling in the server info when more values appear?
Comment 5 Milos Kleint 2001-10-18 19:50:54 UTC
correction: what about NOT to fill in any values in case of problems..
Comment 6 Milos Kleint 2001-10-20 10:27:45 UTC
isn't this an Enhancement rather then Defect? (came to my mind when
reading MArtin's suggestions for solution)
we are just offering a ROOT string so that the user doesn't have to
fill  in everything manually. I guess we didn't ever state the info
*will* be correct all the time. if it were so, we could just skip the
page and get the info fully automatically.it's just our guess what is
the most probable ROOT...
Comment 7 Martin Entlicher 2001-10-23 17:37:54 UTC
O.K., Milos is right. I just made a change, that when relative mount
point is set, the CVS/Root file is searched for under the first
relative mount point selected. I hardly can do more, thus considering
this as fixed.
The fix was applied to build 10/24.
Comment 8 Jiri Kovalsky 2001-10-24 16:38:50 UTC
Hm, it seems that it is not working fully. I mean the case when user 
makes a mistake, gets back to correct his/her decision and selects so-
me relative mount point. The settings are not reloaded.

Steps to reproduce:
===================
1. Perform steps 1. - 4. of procedure above.
2. Do not setup any relative mount point and go "Next >".
3. :local: connection will be loaded. Push "< Back" button.
4. Select some relative mount point and go "Next >" again.
5. You will see that settings remain the same.

Decreasing priority since it is not serious enough to be P3. Trying 
to verify in development build of NetBeans 3.3 #200110240100.
Comment 9 Martin Entlicher 2001-10-25 12:08:36 UTC
You really catch every little inconsistence :-)
Looking at the problem...
Comment 10 Martin Entlicher 2001-10-25 15:12:01 UTC
Fixed in build 10/26.
Hope, that the fix is sufficient now.
Comment 11 Jiri Kovalsky 2001-10-26 11:31:36 UTC
I believe this won't make you angry but there is still little problem 
with :server: connection method. My CVS/Root file contains this string
":server:server:repository" but for some reason wizard reads value of 
%USERNAME% environment variable and places it into "User Name:" text 
field. Therefore CVSROOT is built wrong. The same applies for
":ext:server:repository" method.
Trying to verify in development build of NetBeans 3.3 #200110260100.
Comment 12 Martin Entlicher 2001-10-26 14:48:50 UTC
Well, I hope, that this iterative process of fixes and reopens has a
final limit :-)
Next iteration done in build 10/29.
Comment 13 Jiri Kovalsky 2001-10-30 16:49:21 UTC
I believe we have just reached the end. :-) Verified in development 
build of NetBeans 3.3 #200110301025.
Comment 14 Quality Engineering 2003-07-01 12:58:27 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.