discussed. Use Barrett and Silverman's convention of "SSH-1" for SSH protocol
version 1 and "SSH-2" for protocol 2 ("SSH1"/"SSH2" refer to ssh.com
implementations in this scheme). <http://www.snailbook.com/terms.html>
[originally from svn r5480]
line for every single .but file at the bottom of each page of the
HTML PuTTY docs. However, we can't _always_ replace that with a
single SVN revision, because there isn't always one available (SVN
still allows mixed working copies in which some files are
deliberately checked out against a different revision).
Hence, here's a mechanism for doing better. It uses `svnversion .'
to determine _whether_ a single revision number adequately describes
the current directory, and replaces all the version IDs with that if
so. If it can't do that, it uses the version IDs as before.
Also, this allows an explicit version string to be passed on the
make command line which will override _both_ these possibilities, so
that release documentation can be clearly labelled with the release
version number.
[originally from svn r4804]
and this caused public key authentication to fail in spite of
following our instructions to the letter. It can't hurt to
s/g-w/go-w/ here, just in case!
[originally from svn r4205]
users. Update the file selection dialogs to mention it per the usual Windows
convention, and also sprinkle references to it throughout the docs. I've
also scattered hints that most tools need PuTTY's native format; perhaps this
will reduce the frequency with which FAQ A.1.2 trips people up.
[originally from svn r2625]
might give a bit count one less than the one the user asked for. Two
people have been worried by this now, and it's probably worth
documenting that it's perfectly normal.
[originally from svn r2369]
Updated manual to reflect reality (e.g. usage messages, '-p port' not actually
implemented, sprinkle references to '-i keyfile').
(I've put "Release 0.53" in the messages; let's hope this doesn't cause a
flood of "where is 0.53?" email.)
I don't guarantee that the result is entirely sane and sensible in all
respects, but it is at least consistent.
[originally from svn r1951]
Import command; the former warns you if you load a foreign key,
whereas the latter doesn't. So the user should always be aware, one
way or the other, that a format conversion is taking place.
[originally from svn r1687]
individual documentation of the various PuTTYgen controls; also
implemented context help in PuTTYgen to go with it. Shame there
isn't space for a generic `Help' button in the PuTTYgen window.
[originally from svn r1478]
PuTTY now has a complete manual. Stylistic review, content review
and indexing are yet to do, but at least there's some plausible text
in every section now.
[originally from svn r1460]
than \e when describing button names and menu items: the "Foo"
button rather than the _Foo_ button. Certainly consistent use of
either is better than the mixed use of both we had before :-)
[originally from svn r1420]
added an introduction to public key authentication, and made a
couple of changes in intro.but. Transatlantic flights have some uses
after all.
[originally from svn r1146]
