[This is a needed feature for all kinds of CVS-related tools (existing or potential), for example mirroring the repository to another site (see http://www.cyclic.com/cvs/dev-multisite.html). I'd probably use tagged text ("MT" response), and a new request for the remote protocol, rather than piggybacking this onto "cvs log" as a user-visible feature. That, of course, assumes that clients want to implement the remote protocol; it doesn't address how/whether to make this available at the level of the CVS command line. Providing a way to say "give me foo.html,v just as an RCS file" is another obvious thing, but I don't think I like it as well. The nice thing about "cvs log", as extended here, is that it contains all the information except that which takes up a lot of space. Then a client can fetch delta(s) with "cvs diff -n -r 1.2 -r 1.3 foo.html" or revision(s) with "cvs update -p -r 1.3 foo.html". As for why one needs the "next" field, well, I'm not completely clear on that. tkCVS makes assumptions about numbering which mean that it doesn't need it. For example, if the 1.5 revision has a branch of 1.5.1, then the lowest numbered revision 1.5.1.* (for example, might be 1.5.1.4, can't assume there is a 1.5.1.1) would seem to be it. Would need to think more about "cvs commit -r", "cvs admin -o", and other obscure features to figure out whether there are cases you can't deduce based on the numbers. Probably also want a way to get newphrases, PreservePermissions info, &c. For example, the following is a more or less general scheme for sending fields from the RCS file: MT +rcs-header MT text testofanewphrase: MT testofanewphrase without newphrase we'd have trouble extending @@ all MT newline MT -rcs-header MT +rcs-delta MT text Next: MT next 1.3 MT newline MT -rcs-delta MT +rcs-delta MT text Next: MT next 1.3 MT newline MT -rcs-delta MT +rcs-deltatext MT text newphrase2: MT newphrase2 42 MT newline MT -rcs-deltatext And, as for suppressing it for a regular "cvs log", for clients which support "MT" but would interpret the above as text to print (e.g. stock CVS 1.9.29 client), we could have a general mechanism of "suppress +rcs-deltatext" or "enable +rcs-deltatext" or that kind of thing. -kingdon] Date: Mon, 27 Jul 1998 14:11:40 -0700 From: "John Cavanaugh ; 256095" To: bug-cvs@gnu.org Subject: PATCH: Extended rcsfile meta-data in "cvs log" output Content-Type: multipart/mixed; boundary="/04w6evG8XlLl3ft" --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii This patch allows for an important field (next:) in the rcsfile archives (,v) to be included during a cvs log -x so clients using access methods such as :ext: :server: :pserver: can obtain this information without direct access to the *,v files. If you are wondering why this is important, well its the only way I know of to build an entire version tree for a file. Most tools that build this information internally (tkcvs I think... and cvslines) access the *,v files directly which definately doesnt work on NT or other clients accessing remote repositories. It can be applied with a patch -Np1 < patchfile ----------------------------------------------------------------------- John Cavanaugh Hewlett-Packard Company Project Engineer 1400 Fountaingrove Pkwy EESof Division Santa Rosa, CA 95403-1799 Email: cavanaug@sr.hp.com Phone: 707-577-4780 707-577-3948 (Fax) ----------------------------------------------------------------------- As I grow older, I pay less attention to what men say. I just watch what they do. -- Andrew Carnegie ----------------------------------------------------------------------- --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=cvs-patch-log_extended_metadata diff -Naur cvs-1.9.28/doc/cvs.texinfo cvs-1.9.28_HP/doc/cvs.texinfo --- cvs-1.9.28/doc/cvs.texinfo Tue May 12 15:41:43 1998 +++ cvs-1.9.28_HP/doc/cvs.texinfo Mon Jul 27 13:42:42 1998 @@ -9019,13 +9019,22 @@ @node log options @appendixsubsec log options -By default, @code{log} prints all information that is -available. All other options restrict the output. +By default, @code{log} prints all standard information that is +available. All other options (with the exception of -x) restrict the +output. @table @code @item -b Print information about the revisions on the default branch, normally the highest branch on the trunk. + +@item -x +This is the only option that does not restrict output, instead it +shows extended rcsfile meta-data information. Specifically, additional +information is provided about a particular revisions next node. This +allows clients using :ext:server:pserver: to gather information +necessary to construct a full version tree for a particular file without +having direct access to the RCS archive ,v files. @item -d @var{dates} Print information about revisions with a checkin diff -Naur cvs-1.9.28/src/log.c cvs-1.9.28_HP/src/log.c --- cvs-1.9.28/src/log.c Thu Jan 22 07:05:49 1998 +++ cvs-1.9.28_HP/src/log.c Mon Jul 27 13:43:51 1998 @@ -98,6 +98,9 @@ /* If not NULL, the list of login names given for the -w option, which only prints revisions checked in by given users. */ List *authorlist; + /* Nonzero if the -x option was given, meaning that extended information + such as the next node should be displayed. */ + int extended_info; }; /* This structure is used to pass information through walklist. */ @@ -144,6 +147,7 @@ "\t-t\tOnly print header and descriptive text.\n", "\t-N\tDo not list tags.\n", "\t-b\tOnly list revisions on the default branch.\n", + "\t-x\tShow extended rcsfile meta-data.\n", "\t-r[revisions]\tSpecify revision(s)s to list.\n", "\t-d dates\tSpecify dates (D1branches, log_branch, (void *) NULL); + } + + if (log_data->extended_info == 1) + { + cvs_output ("\nnext: ", 0); + if (ver->next != NULL) + cvs_output (ver->next, 0); } cvs_output ("\n", 1); --/04w6evG8XlLl3ft--