Re: backwards compatibility problem with .cvspass?

[Derek R. Price]

Karl Fogel wrote:

> I haven't debugged this at all, because there's probably a simple
> answer that someone already knows.  Right? :-)
>
> I just built the latest trunk cvs, but haven't installed it.  But now
> these two commands in my working tree get different results:
>
>    prompt$ /usr/local/bin/cvs up             /* using the old cvs */
>    [normal update output, everything fine]
>
>    prompt$ src/cvs up                        /* using the new cvs */
>    cvs update: authorization failed: server cvs.cyclic.com \
>    rejected access to /home2/cvsroot for user kfogel
>    cvs update: used empty password; try "cvs login" with a real password
>
> Hmm.  That's bad.  The NEWS file has these two items:
>
>    * The ~/.cvspass file has a slightly modified format.  Now two
>    slightly different CVSROOTs which represent the same repository and
>    user name no longer require separate calls to 'cvs login' to use.
>    The new code should be backwards compatible with the old file
>    format unless you have an old password entry for a host name
>    containing capital letters.  In this case the new version of CVS
>    will be unable to log out.  The workaround for this is to log out
>    using an old version of CVS or delete the appropriate line from
>    ~/.cvspass, then log in with the new version.

This is really just referring to the fact that username, port number, and a
lower case hostname are always included in the .cvspass file now regardless
of the literal CVSROOT.  The complete feature would be to use a FQDN every
time, but this isn't the source of your problem.


>    * A password and a port number may now be specified in CVSROOT for
>    pserver connections.  The new format is:
>
>       :pserver:[[user][:password]@]host[:[port]]/path
>
>    Note that passwords specified in a checkout command will be saved
>    in the clear in the CVS/Root file in each created directory, so
>    this is not recommended, except perhaps when accessing anonymous
>    repositories or the like.

This is the source of your problem.  When _this_ feature went in, I decided
that since I've seen several emails asking or telling about using
non-default port numbers over the last few years that I would not assume
that an entry in .cvspass without a port number meant port 2401.  This
seemed the lesser of two evils since the people who used to use non-default
port numbers would have seen an obscure error message (server not
responding) which may have been hard to debug versus everyone having to
relogin to each server they use once after seeing an error message they
should have already been familiar with.

The other half of this workaround/fix/upgrade procedure/whatever is that
whenever you decide you are finished with the old versions of CVS (pre
1.11.0.1) you can use them to 'cvs logout' the old entries or delete the
old lines from .cvspass.


> But the result doesn't look backwards-compatible to me so far. :-)
>
> Am I missing something silly here?  Or (worst case) does the current
> code break people's existing working-copy & .cvspass combinations?

So, yes and yes.  I'll annotate the port entry in NEWS.  Please feel free
to argue if you think asking for the extra login is not the lesser of two
evils.

Derek

--
Derek Price                      CVS Solutions Architect ( http://CVSHome.org )
mailto:dprice@openavenue.com     OpenAvenue ( http://OpenAvenue.com )
--
If you can read this, please flip me back over... (seen upside down, on a Jeep)