[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: New Subclipse release - feedback on user/password change

From: sebb <sebbaz_at_gmail.com>
Date: 2005-11-25 18:22:33 CET

On 25/11/05, Mark Phippard <markp@softlanding.com> wrote:
> sebb <sebbaz@gmail.com> wrote on 11/25/2005 11:27:03 AM:
> > On 25/11/05, Mark Phippard <markp@softlanding.com> wrote:
> > > Details of all that is coming can be found in the changelog.
> > >
> > > http://subclipse.tigris.org/subclipse/changes.html
> >
> > Includes:
> >
> > " * Repository connection no longer shows username and password
> fields"
> >
> > I can understand why the password is not stored (though I think it
> > should be up to the user), but I can't see why the username is no
> > longer being stored.
> >
> > I'd prefer to see the same behaviour as for CVS, i.e. username and
> > password can be optionally stored. If one or both are missing, they
> > are prompted for and then cached for the rest of the Eclipse session.
> Because for a long time it has been the case that it is a bad thing that
> this information is stored in Subclipse. It has to do with how Subclipse
> interacts with the underlying client adapters. Basically, it is better to
> just let the client adapter own this information and ask for it when
> needed.
> Consider the case the values in Subclipse are invalid. What happens is we
> pass these to the client adapter. It tries to use them and it fails. So
> the adapter then prompts you for new values, which work. The problem is
> that Subclipse does not know that you were prompted, so it has no way to
> update the stored values. Consequently, the next time you try to do an
> operation which needs credentials you go through this process all over
> again.

If they are then changed in the dialogue box, it will then work from then on.

> It is just better if this information is not stored at all in Subclipse.
> Comparisons with CVS are unfair as it has complete end to end control of
> the solution where as Subclipse has to interact with a library that comes
> from some place else.

That may be so (at present), but as far as the user is concerned, all
they see is the Subclipse interface.

> Finally, I will just point out that when the command line adapter is used
> then you can still specify the username and password as that adapter does
> not have any prompting support and therefore needs the information to be
> passed in.

OK, so why not leave it up to the user whether or not they want to
store the information in Subclipse - for all connectors?

Received on Sat Nov 26 04:22:33 2005

This is an archived mail posted to the Subclipse Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.