sebb <firstname.lastname@example.org> wrote on 11/25/2005 11:27:03 AM:
> On 25/11/05, Mark Phippard <email@example.com> wrote:
> > Details of all that is coming can be found in the changelog.
> > http://subclipse.tigris.org/subclipse/changes.html
> " * Repository connection no longer shows username and password
> 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
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
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.
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
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
Received on Sat Nov 26 03:33:12 2005