RFC: Reworking server handling of case insensitive clients

[Derek Robert Price]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey all,

More on the case insensitivity handling discussion.  Though I put a note
in cvsclient.texi asking client developers to stop using the Case
request, since this should allow case sensitive and case insensitive
clients to cooperate seamlessly, I want to fix the server side handling
of case insensitive clients too.

In any case, I've included a case-by-case analysis of the server side
handling, as Larry Jones suggested someone should do some weeks ago.
Basically, what I am proposing is writing a tag filter that filters a
list of matched files according to any revisions or tags specified for
commands by the user.

Please review and comment!

Goal:

Rewrite CVS file location routines to filter the list of located files based
on the command being run and the revisions/tags requested.



Initial analysis:

This is going to require a fairly major overhaul since many high level
functions are going to require command and tag info.  The base command is
stored in a global variable and easy to get access to, but the filter
mode is
going to depend on the options supplied to that command as well.  For
instance:

Let, "matching files", denote files whose names case insensitively match the
requested file.

Any selection criteria which matches multiple files will cause a fatal error
unless specifically denoted otherwise.

Then: admin -kb will wish to access all matching files; admin -nNAME:REV
will
require only files which contain REV; add will require all matching
files; diff
- -rREV1 -rREV2 will require files containing REV1 or REV2; remove will
require a
match based on the CVS/Entries entry of the workspace file.



Command specific analysis:

Command
~  options    Match criteria
_______________
______________________________________________________________
add
~  all        All files.  Needs to be capable of resurrecting a file.


admin
       Called recursively, this command usually causes all archives to
       be operated upon, regardless of whether they are in the Attic
       or not.  This leaves some question about what this should mean
       should the user reference a file in the sandbox by name.  It
       could either be assumed that the user meant the file which was
       checked out into the sandbox, as determined by the entry in
       CVS/Entries, or it could mean all matching files in the
       repository.  Actually allowing the operation on all matching
       files in the repository is almost certainly the wrong thing to
       do though a fatal error message may be reasonable, but matching
       via CVS/Entries may not hurt.  I am leaning towards the
       CVS/Entries match since this allows matches in some cases and
       the alternative requires the repository to be repaired.

~  -b        !Attic
~  -b"HEAD"    !Attic
~  -bREV        REV exists in file
~  -l[REV]    Per -b
~  -m REV:MSG    REV exists in file
~  -n TAG    TAG exists in file
~  -n TAG:    !Attic
~  -n TAG:"HEAD"    !Attic
~  -n TAG:REV    REV exists in file
~  -N TAG:[REV]    Per -n
~  -o range    REV1 and [REV2] exist in file.  This may be incorrect for
       recursive operation.  If either is "HEAD", !Attic.
~  -s STATE:"HEAD"
       !Attic.
~  -s STATE:REV    REV exists in file
~  -u[REV]    Per -b


annotate
~  CVS/Entries    Match case exactly since client is required to
preserve it,
       except when a -r option is specified.
~  -r"HEAD"    !Attic, overrides CVS/Entries.
~  -r REV    REV exists in file, overrides CVS/Entries.


checkout
~  CVS/Entries    Only matters in the case where checkout of an existing
sandbox
       becomes an update.  Then apply criteria as per update, not
       checkout.
~  -r"HEAD"    !Attic.
~  -r REV    REV exists in file
~  -j REV1    No effect, as per diff -r and update -j.
~  -j REV2    No effect, as per diff -r and update -j.


commit
~  CVS/Entries    Match case exactly since client is required to
preserve it.  In
       the case of the commit of an add, accept any match.
~  -r        Irrelevant, since commit requires a checked out version of the
       file and we may then consult CVS/Entries.


diff
~  CVS/Entries    Match case exactly since client is required to
preserve it,
       except when a -r option is specified.
~  -r "HEAD"    Matches head of current branch, so as per CVS/Entries.
~  -r REV1    File containing REV not attached to a dead revision.  If the
       file list comes up empty using this criteria, then the diff is
       against /dev/null (as per the -N option and Larry Wall's patch
       specification).  Overrides CVS/Entries for REV1.
~  -r REV2    Per -r REV1, except for override.  The results of this search
       override the contents of the file in the sandbox but cause an
       additional search - there is no search criteria to override.


edit
~  CVS/Entries    Match case exactly since client is required to
preserve it.


editors
       This is open to the same sort of speculation as admin.


export
~  -r"HEAD"    !Attic.
~  -r REV    REV exists in file


history
       Does not act on RCS archives.


import
       VENDOR-TAG exists in file, but if it doesn't exist, may match
       any file and create VENDOR-TAG.


init
       Does not act on RCS archives.


log
~  CVS/Entries    Match case exactly since client is required to
preserve it,
       except when a -r option is specified.
~  -rREVISONS    REV1 or [REV2] exist in file.  This is not an _and_ because
       that might neglect to inform a user about a file which, for
       instance, they later removed and which is therefore missing
       REV2.  If either REV is "HEAD", then !Attic.


login
logout
pserver
       These commands do not act on RCS archives.


rannotate
~  -r"HEAD"    !Attic.
~  -r REV    REV exists in file.


rdiff
~  -r "HEAD"    !Attic.
~  -r REV1    File containing REV not attached to a dead revision.  If the
       file list comes up empty using this criteria, then the diff is
       against /dev/null (as per the -N option and Larry Wall's patch
       specification).
~  -r REV2    Per -r REV1.


release
~  CVS/Entries    Match case exactly since client is required to
preserve it.


remove
~  CVS/Entries    Match case exactly since client is required to
preserve it.


rlog
~  -rREVISONS    REV1 or [REV2] exist in file.  This is not an _and_ because
       that might neglect to inform a user about a file which, for
       instance, they later removed and which is therefore missing
       REV2.  If either REV is "HEAD", then !Attic.


rtag
~  -r "HEAD"    !Attic.
~  -r REV    REV exists in file.


server
       Does not act on RCS archives.


tag
~  CVS/Entries    Match case exactly since client is required to
preserve it,
       except when a -r option is specified.
~  -r "HEAD"    !Attic.
~  -r REV    REV exists in file.


unedit
~  CVS/Entries    Match case exactly since client is required to
preserve it.


update
~  CVS/Entries    Match case exactly since client is required to
preserve it,
       except when a -r option is specified.
~  -r "HEAD"    !Attic.
~  -r REV    REV exists in file.
~  -j REV1    No effect, as per diff -r & checkout -j.
~  -j REV2    No effect, as per diff -r & checkout -j.


version
       Does not act on RCS archives.


watch
~  CVS/Entries    Match case exactly since client is required to
preserve it.


watchers
       This is open to the same sort of speculation as admin.



Regression Test Suite

This is going to require some major overhaul to work correctly and will also
require being run on a system with both a case-sensitive and
case-insensitive
file system available.



Additional Notes

It turns out that the CVS client/server protocol specification specifies
that
clients will preserve case in Entries, so the server may count on this
behavior
and use that filename value to look for archives case-sensitively rather
than
going through the case-insensitive lookup and thus the filter
functions.  This
fix may be viable on the stable branch if not already implemented.



Derek

- --
~                *8^)

Email: derek@ximbiot.com

Get CVS support at <http://ximbiot.com>!
- --
All those who believe in psychokinesis raise my hand.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE/geWZLD1OTBfyMaQRAs0bAKDYsavvv4p6Wp663Wxseb0gWTgBmwCfdDVi
OHB+UUSrT63lUAJj6bMJxsQ=
=CXgt
-----END PGP SIGNATURE-----