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 7832 - "Refresh Recursively" command doesn't work well if bad repository is entered.
Summary: "Refresh Recursively" command doesn't work well if bad repository is entered.
Status: CLOSED FIXED
Alias: None
Product: obsolete
Classification: Unclassified
Component: vcscvs (show other bugs)
Version: 3.x
Hardware: All All
: P4 minor (vote)
Assignee: issues@obsolete
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2000-10-09 11:44 UTC by Jiri Kovalsky
Modified: 2003-07-02 17:20 UTC (History)
1 user (show)

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 2000-10-09 11:44:53 UTC
Discovered in: CE/IE Build 1117 on Windows 2000, Red Hat Linux 6.2, Solaris 5.8
============== (all with JDK 1.3)

Description:
============
If user makes mistake and sets for certain working directory wrong repository
during mounting CVS filesystem "Refresh Recursively" command then works bad. It
places all files that are inside some directory into the root with [Up-to-date]
status and doesn't assign [Missing] status to files that are not checked out
yet from the repository.

Note: I understand that this bug is very complicated to fix so if there is no
===== simple solution it would be quite enough to show warning dialog that user
      made a mistake and filesystem points to incorrect repository.

Steps to reproduce:
===================
1. Prepare two different CVS filesystems that have completely different
   contents. E.g. /test/work1 for /test/repo1 and /test/work2 for /test/repo2
2. Now try to mount the arbitrary one of them and simulate your mistake by
   entering wrong repository. E.g. /test/work1 and /test/repo2
3. You will be prompted to answer "Refresh contents of VCS recursively ?"
   question dialog. Click on "Yes" button.
4. After the filesystem is refreshed you will see that its contents doesn't
   reflect true state.
Comment 1 Martin Entlicher 2000-11-01 20:40:59 UTC
Files will have status [Local] when the repository can not be found.
Comment 2 Martin Entlicher 2000-11-02 18:42:59 UTC
Fixed in main trunk (#62) and in boston branch (#1137).
Comment 3 Jiri Kovalsky 2000-12-08 16:03:59 UTC
To tell the truth the fix was not probably generic. The behaviour now is this:

Netbeans 3.1 & Community Edition 2.0:
=====================================
"Refresh Recursively" immediately after mounting works as fixed (remains
[Local]), but if "Refresh" is invoked on some file it changes to [Up-to-date]
in spite of wrong repository set in mounting wizard.

Internet Edition:
=================
The behaviour remains exactly as described in this bug. It looks like the fix
was not performed for this branch at all.

The best way how to solve this user's mistake would be the simple question
dialog that would warn user where is the problem and suggest him to change path
to the correct repository (got from /CVS/Repository).
Due to this bug can't be verified yet.
BUG also appears in version : FFJ20
Comment 4 Martin Entlicher 2000-12-11 10:23:59 UTC
The above description is the correct behavior.
- recursive refresh is not able to find out the correct folder due to bad
CVSROOT configuration => the files are [Local]
- refresh (of a single folder) knows which folder it is refreshing and therefore
can set the status correctly (cvs status returns the right info because it can
get it from CVS/Root)

- Internet Edition: its currectly being changed to use vcscore, so I do no
bugfixes to the IE now. Moreover bugs in IE should not be mentioned here and
should not prevent bugs in open source being fixed.

Due to above, I mark it as fixed again.
Comment 5 dmladek 2001-01-08 19:44:59 UTC
It behaves exactly as it's described...
so I verify this bugfix is OK.
But this solution might confuse users
so I entered new RFE bug #9036
Comment 6 Quality Engineering 2003-07-02 17:20:25 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.