Bug 43840 - New read connection still using extssh
Summary: New read connection still using extssh
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Team (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.0 M8   Edit
Assignee: Michael Valenta CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 44458 46541 53765 (view as bug list)
Depends on: 36965
Blocks:
  Show dependency tree
 
Reported: 2003-09-29 12:31 EDT by Dani Megert CLA
Modified: 2004-03-22 19:36 EST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dani Megert CLA 2003-09-29 12:31:02 EDT
I20030525

I setup my repository connection to use pserver for read access. When I now
expand nodes in the CVS Repository view it still says: "Retrieving children -
authenticating over extssh".

Also, in the new Sync view when I click files (to compare) with outgoing changes
they use extssh (or at least the dialog tells so).
Comment 1 Jean-Michel Lemieux CLA 2003-09-29 13:25:45 EDT
Do you mean I20030925? I can't reproduce this. I also put a breakpoint in the 
ssh open connection and it's never called when read connection is configured.
Comment 2 Dani Megert CLA 2003-09-30 04:34:24 EDT
Yes I20030925. I did not debug it. I only reported what I see in the UI
(dialogs) maybe it's doing something else behind the back.
Comment 3 Dani Megert CLA 2003-09-30 06:48:04 EDT
Note: it is really much faster (cool!). My PR is just about the dialog/status
line. Maybe it is the first connection when it displays extssh (before redirecting)?
Comment 4 Dani Megert CLA 2003-10-01 05:10:53 EDT
Saw this again today (have a witness :-). It seems to be reproducible by
starting the workspace with sync view in the perspective and then clicking on
some files (so that the compare editor opens - I use single-click mode).
Comment 5 Jean-Michel Lemieux CLA 2003-10-03 15:25:30 EDT
Mike, you can look into this when we improve the read/write repo UI and 
support.
Comment 6 Michael Valenta CLA 2003-10-03 15:42:54 EDT
I suspect this has to do with the loading order of plugins. The read/write 
repo locations are stored in core but persisted by the UI (I know it doesn't 
make since but it was a lot simpler and cleaner to implement because the UI 
mechanism is XML based and the core one isn't). Anyway, if a connection was 
attempted before the UI had loaded and initialized it's settings, this 
behavior would occur. I will verify this when we improve the support of this 
feature.
Comment 7 Michael Valenta CLA 2003-10-08 13:27:08 EDT
*** Bug 44458 has been marked as a duplicate of this bug. ***
Comment 8 Michael Valenta CLA 2003-11-13 09:13:46 EST
*** Bug 46541 has been marked as a duplicate of this bug. ***
Comment 9 Dani Megert CLA 2004-01-07 04:02:22 EST
Any change that this get fixed soon? Every time when starting my workspace and
doing CVS reads (from the Team view) I first have to go to another view (e.g.
Package Explorer) and do some CVS operation, otherwise it uses extsh and of
course my time.
Comment 10 Michael Valenta CLA 2004-01-07 09:15:37 EST
Were hoping that the user setting support will help us here so were waiting to 
see what the final incarnation of that is.
Comment 11 Markus Keller CLA 2004-02-11 05:13:11 EST
A manual workaround after the wrong connetion is used:
- open the CVS Repositories view
- edit the extssh connection
- re-select the pserver for read
- press OK
Comment 12 Dani Megert CLA 2004-02-18 04:19:22 EST
Now that I am using SSH2 (which works great) this is becoming a bigger pain:
On startup the UI hangs waiting for my password for the SSH2 authentication.
This gets caused by quick diff that accesses the repository. Though this is
basically correct it shouldn't do this via SSH2 since I've setup anonymous repos
for read access.
Comment 13 Michael Valenta CLA 2004-02-18 09:44:04 EST
With the new SSH2 support, the intention was to remove the read/write 
configurability since SSH2 is faster due to connection reuse. However, we will 
also need to consider the case you just mentioned. We will look into this in 
M8.
Comment 14 Dani Megert CLA 2004-02-19 04:12:55 EST
>With the new SSH2 support, the intention was to remove the read/write 
>configurability since SSH2 is faster due to connection reuse.
Faster than anonymous access using pserver?
Comment 15 Michael Valenta CLA 2004-02-19 09:40:30 EST
Potentially, since the connection is only made once and all further 
communications are done over that channel. It's hard to say whether the cost 
of encrypting/decrypting the packets is more or less than the cost of opening 
a socket (or 2 or 3) for each project being refreshed. However, there is still 
quite a bit of work required to make the read/write location feature "real" so 
the tradeoff really involves whether we have the cycles to complete the 
feature properly since, at this point, it is not ready for a released product. 
This bug is actually the easiest part to fix. The complicated portion is how 
to surface the UI in a way that makes sense. 
Comment 16 Michael Valenta CLA 2004-03-04 11:57:15 EST
*** Bug 53765 has been marked as a duplicate of this bug. ***
Comment 17 Michael Valenta CLA 2004-03-22 19:36:43 EST
Fix released to HEAD. The read/write locations are now stored in the instance 
preferences.