diff options
Diffstat (limited to 'gnu/usr.bin/cvs/doc/cvsclient.info')
| -rw-r--r-- | gnu/usr.bin/cvs/doc/cvsclient.info | 237 |
1 files changed, 122 insertions, 115 deletions
diff --git a/gnu/usr.bin/cvs/doc/cvsclient.info b/gnu/usr.bin/cvs/doc/cvsclient.info index ecfdce468b9..61ac9062947 100644 --- a/gnu/usr.bin/cvs/doc/cvsclient.info +++ b/gnu/usr.bin/cvs/doc/cvsclient.info @@ -7,11 +7,14 @@ File: cvsclient.info, Node: Top, Next: Goals, Prev: (DIR), Up: (DIR) CVS Client/Server ***************** + This manual describes the client/server protocol used by CVS. It +does not describe how to use or administer client/server CVS; see the +regular CVS manual for that. + * Menu: * Goals:: Basic design decisions, requirements, scope, etc. * Notes:: Notes on the current implementation -* How To:: How to remote your favorite CVS command * Protocol Notes:: Possible enhancements, limitations, etc. of the protocol * Protocol:: Complete description of the protocol @@ -50,7 +53,7 @@ Goals whenever it waits for the client makes it complicated. -File: cvsclient.info, Node: Notes, Next: How To, Prev: Goals, Up: Top +File: cvsclient.info, Node: Notes, Next: Protocol Notes, Prev: Goals, Up: Top Notes on the Current Implementation *********************************** @@ -73,99 +76,13 @@ does an initial Kerberos authentication on stdin. If the authentication succeeds, it subsequently runs identically to `cvs server'. The current server implementation can use up huge amounts of memory -when transmitting a lot of data. Avoiding this would be a bit tricky -because it is not acceptable to have the server block on the network -(which may be very slow) when it has locks open. The buffer code has -been rewritten so that this does not appear to be a serious problem in -practice. However, if it is seen to be a problem several solutions are -possible. The two-pass design would involve first noting what versions -of everything we need (with locks in place) and then sending the data, -blocking on the network, with no locks needed. The lather-rinse-repeat -design would involve doing things as it does now until a certain amount -of server memory is being used (10M?), then releasing locks, and trying -the whole update again (some of it is presumably already done). One -problem with this is getting merges to work right. - - -File: cvsclient.info, Node: How To, Next: Protocol Notes, Prev: Notes, Up: Top - -How to add more remote commands -******************************* - - It's the usual simple twelve step process. Let's say you're making -the existing `cvs fix' command work remotely. - - * Add a declaration for the `fix' function, which already implements - the `cvs fix' command, to `server.c'. - - * Now, the client side. Add a function `client_fix' to `client.c', - which calls `parse_cvsroot' and then calls the usual `fix' - function. - - * Add a declaration for `client_fix' to `client.h'. - - * Add `client_fix' to the "fix" entry in the table of commands in - `main.c'. - - * Now for the server side. Add the `serve_fix' routine to - `server.c'; make it do: - static void - serve_fix (arg) - char *arg; - { - do_cvs_command (fix); - } - - * Add the server command `"fix"' to the table of requests in - `server.c'. - - * The `fix' function can now be entered in three different - situations: local (the old situation), client, and server. On the - server side it probably will not need any changes to cope. Modify - the `fix' function so that if it is run when the variable - `client_active' is set, it starts the server, sends over parsed - arguments and possibly files, sends a "fix" command to the server, - and handles responses from the server. Sample code: - if (!client_active) { - /* Do whatever you used to do */ - } else { - /* We're the local client. Fire up the remote server. */ - start_server (); - - if (local) - if (fprintf (to_server, "Argument -l\n") == EOF) - error (1, errno, "writing to server"); - send_option_string (options); - - send_files (argc, argv, local); - - if (fprintf (to_server, "fix\n") == EOF) - error (1, errno, "writing to server"); - err = get_responses_and_close (); - } - - * Build it locally. Copy the new version into somewhere on the - remote system, in your path so that `rsh host cvs' finds it. Now - you can test it. - - * You may want to set the environment variable `CVS_CLIENT_PORT' to - -1 to prevent the client from contacting the server via a direct - TCP link. That will force the client to fall back to using `rsh', - which will run your new binary. - - * Set the environment variable `CVS_CLIENT_LOG' to a filename prefix - such as `/tmp/cvslog'. Whenever you run a remote CVS command, the - commands and responses sent across the client/server connection - will be logged in `/tmp/cvslog.in' and `/tmp/cvslog.out'. Examine - them for problems while you're testing. - - This should produce a good first cut at a working remote `cvs fix' -command. You may have to change exactly how arguments are passed, -whether files or just their names are sent, and how some of the deeper -infrastructure of your command copes with remoteness. +when transmitting a lot of data over a slow link (i.e. the network is +slower than the server can generate the data). There is some +experimental code (see `SERVER_FLOWCONTROL' in options.h) which should +help significantly. -File: cvsclient.info, Node: Protocol Notes, Next: Protocol, Prev: How To, Up: Top +File: cvsclient.info, Node: Protocol Notes, Next: Protocol, Prev: Notes, Up: Top Notes on the Protocol ********************* @@ -205,6 +122,9 @@ File: cvsclient.info, Node: Protocol, Prev: Protocol Notes, Up: Top The CVS client/server protocol ****************************** + In the following, `\n' refers to a linefeed and `\t' refers to a +horizontal tab. + * Menu: * Entries Lines:: @@ -247,17 +167,28 @@ Modes separated by `,'. MODE-TYPE is an identifier composed of alphanumeric characters. -Currently specified: `u' for user, `g' for group, `o' for other, as -specified in POSIX. If at all possible, give these their POSIX meaning -and use other mode-types for other behaviors. For example, on VMS it -shouldn't be hard to make the groups behave like POSIX, but you would -need to use ACLs for some cases. +Currently specified: `u' for user, `g' for group, `o' for other (see +below for discussion of whether these have their POSIX meaning or are +more loose). Unrecognized values of MODE-TYPE are silently ignored. DATA consists of any data not containing `,', `\0' or `\n'. For `u', `g', and `o' mode types, data consists of alphanumeric characters, where `r' means read, `w' means write, `x' means execute, and unrecognized letters are silently ignored. + The two most obvious ways in which the mode matters are: (1) is it +writeable? This is used by the developer communication features, and +is implemented even on OS/2 (and could be implemented on DOS), whose +notion of mode is limited to a readonly bit. (2) is it executable? +Unix CVS users need CVS to store this setting (for shell scripts and +the like). The current CVS implementation on unix does a little bit +more than just maintain these two settings, but it doesn't really have +a nice general facility to store or version control the mode, even on +unix, much less across operating systems with diverse protection +features. So all the ins and outs of what the mode means across +operating systems haven't really been worked out (e.g. should the VMS +port use ACLs to get POSIX semantics for groups?). + File: cvsclient.info, Node: Requests, Next: Responses, Prev: Modes, Up: Protocol @@ -381,6 +312,27 @@ compressed form) ends with a newline. the server knows what possible files may exist, and thus what files are nonexistent. +`Notify FILENAME \n' + Tell the server that a `edit' or `unedit' command has taken place. + The server needs to send a `Notified' response, but such response + is deferred until the next time that the server is sending + responses. Response expected: no. Additional data: + NOTIFICATION-TYPE \t TIME \t CLIENTHOST \t + WORKING-DIR \t WATCHES \n + where NOTIFICATION-TYPE is `E' for edit or `U' for unedit, TIME is + the time at which the edit or unedit took place, CLIENTHOST is the + name of the host on which the edit or unedit took place, and + WORKING-DIR is the pathname of the working directory where the + edit or unedit took place. WATCHES are the temporary watches to + set; if it is followed by \t then the tab and the rest of the line + are ignored. + +`Questionable FILENAME \n' + Response expected: no. Additional data: no. Tell the server to + check whether FILENAME should be ignored, and if not, next time the + server sends responses, send (in a `M' response) `?' followed by + the directory and filename. + `Argument TEXT \n' Response expected: no. Save argument for use in a subsequent command. Arguments accumulate until an argument-using command is @@ -405,7 +357,6 @@ compressed form) ends with a newline. and thus have no need to expand modules on the client side. `co \n' -`update \n' `ci \n' `diff \n' `tag \n' @@ -415,11 +366,11 @@ compressed form) ends with a newline. `remove \n' `rdiff \n' `rtag \n' -`import \n' `admin \n' `export \n' `history \n' -`release \n' +`watchers \n' +`editors \n' Response expected: yes. Actually do a cvs command. This uses any previous `Argument', `Repository', `Entry', `Modified', or `Lost' requests, if they have been sent. The last `Repository' sent @@ -427,6 +378,47 @@ compressed form) ends with a newline. provision is made for any input from the user. This means that `ci' must use a `-m' argument if it wants to specify a log message. +`update \n' + Response expected: yes. Actually do a `cvs update' command. This + uses any previous `Argument', `Repository', `Entry', `Modified', + or `Lost' requests, if they have been sent. The last `Repository' + sent specifies the working directory at the time of the operation. + The `-I' option is not used-files which the client can decide + whether to ignore are not mentioned and the client sends the + `Questionable' request for others. + +`import \n' + Response expected: yes. Actually do a `cvs import' command. This + uses any previous `Argument', `Repository', `Entry', `Modified', + or `Lost' requests, if they have been sent. The last `Repository' + sent specifies the working directory at the time of the operation. + The files to be imported are sent in `Modified' requests (files + which the client knows should be ignored are not sent; the server + must still process the CVSROOT/cvsignore file unless -I ! is + sent). A log message must have been specified with a `-m' + argument. + +`watch-on \n' +`watch-off \n' +`watch-add \n' +`watch-remove \n' + Response expected: yes. Actually do the `cvs watch on', `cvs + watch off', `cvs watch add', and `cvs watch remove' commands, + respectively. This uses any previous `Argument', `Repository', + `Entry', `Modified', or `Lost' requests, if they have been sent. + The last `Repository' sent specifies the working directory at the + time of the operation. + +`release \n' + Response expected: yes. Note that a `cvs release' command has + taken place and update the history file accordingly. + +`noop \n' + Response expected: yes. This request is a null command in the + sense that it doesn't do anything, but merely (as with any other + requests expecting a response) sends back any responses pertaining + to pending errors, pending `Notified' responses, etc. + `update-patches \n' This request does not actually do anything. It is used as a signal that the server is able to generate patches when given an @@ -519,6 +511,11 @@ the response is over. an earlier revision of a file. This response is only used if the `update' command is given the `-u' argument. +`Mode MODE \n' + This MODE applies to the next file mentioned in `Checked-in'. It + does not apply to any request which follows a `Checked-in', + `New-entry', `Updated', `Merged', or `Patched' response. + `Checksum CHECKSUM\n' The CHECKSUM applies to the next file sent over via `Updated', `Merged', or `Patched'. In the case of `Patched', the checksum @@ -574,10 +571,21 @@ the response is over. program, which should be supplied with the `Update-prog' request for future operations. -`Module-expansion PATHNAME \n' - Return a file or directory which is included in a particular - module. PATHNAME is relative to cvsroot, unlike most pathnames in - responses. +`Notified PATHNAME \n' + Indicate to the client that the notification for PATHNAME has been + done. There should be one such response for every `Notify' + request; if there are several `Notify' requests for a single file, + the requests should be processed in order; the first `Notified' + response pertains to the first `Notify' request, etc. + +`Module-expansion PATHNAME \n Return a file or directory' + which is included in a particular module. PATHNAME is relative to + cvsroot, unlike most pathnames in responses. PATHNAME should be + used to look and see whether some or all of the module exists on + the client side; it is not necessarily suitable for passing as an + argument to a `co' request (for example, if the modules file + contains the `-d' option, it will be the directory specified with + `-d', not the name of the module). `M TEXT \n' A one-line message for the user. @@ -653,15 +661,14 @@ of the actual exchange. Tag Table: Node: Top99 -Node: Goals552 -Node: Notes2049 -Node: How To3893 -Node: Protocol Notes7058 -Node: Protocol8741 -Node: Entries Lines8955 -Node: Modes9663 -Node: Requests10483 -Node: Responses19350 -Node: Example25504 +Node: Goals659 +Node: Notes2156 +Node: Protocol Notes3400 +Node: Protocol5082 +Node: Entries Lines5381 +Node: Modes6089 +Node: Requests7611 +Node: Responses19467 +Node: Example26529 End Tag Table |