rlog questions
Is there any reason not to use the -n option to cvs when calling rlog? Is there a way to run rlog without getting the comment entries in the output? Thanks, Mark ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: rlog questions
Mark O'Brien wrote: Is there any reason not to use the -n option to cvs when calling rlog? None that I can think of offhand. Is there a way to run rlog without getting the comment entries in the output? Have a look at the rlog options (cvs --help rlog) - there are several options that suppress various parts of the output. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs rlog -rTAG1::TAG2 doesn't handle newly added files
Matthew Herrmann writes: I upgraded to 1.11.9 but this didn't solve the problem. Sorry, I knew there were a number of fixes to that code and I was hoping that they would fix the problem. Now that I think about it a bit more, however, I don't think it's fixable. I don't think there's any way for CVS to intuit, in the general case, what a missing tag should mean. For example, if it's the end tag that is missing and there's more than one branch past the start tag, which branch should CVS follow? -Larry Jones Oh, now don't YOU start on me. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvs rlog -rTAG1::TAG2 doesn't handle newly added files
Hi Larry, But the problem of missing tags should only come up when a file initially doesn't exist, and then does. The reverse cannot happen because the dead revision should still be tagged, shouldn't it(?) if the file is removed via cvs rm. The only exception would be a faulty tagging process where the file wasn't tagged with others. In that case I would say it's a faulty behaviour coming from incorrect use. The alternative of faulty behaviour from correct use is more serious. The branching problem you mentioned doesn't come up for the coming up into existence problem, because every file always starts from 1.1. Said another way, every file has a single beginning, but multiple possible ends. In this case, my suggestion of selecting every revision up to the end tag makes sense, doesn't it? People's thoughts? -- Matthew -Original Message- From: Larry Jones [mailto:[EMAIL PROTECTED] Sent: Wednesday, 3 December 2003 7:48 AM To: Matthew Herrmann Cc: CVS Mailing List Subject: Re: cvs rlog -rTAG1::TAG2 doesn't handle newly added files Matthew Herrmann writes: I upgraded to 1.11.9 but this didn't solve the problem. Sorry, I knew there were a number of fixes to that code and I was hoping that they would fix the problem. Now that I think about it a bit more, however, I don't think it's fixable. I don't think there's any way for CVS to intuit, in the general case, what a missing tag should mean. For example, if it's the end tag that is missing and there's more than one branch past the start tag, which branch should CVS follow? -Larry Jones Oh, now don't YOU start on me. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvs rlog -rTAG1::TAG2 doesn't handle newly added files
Hi All, I upgraded to 1.11.9 but this didn't solve the problem. Maybe the fix in 1.11.9 for this problem was only for the precise case where the file was created after, but wasn't modified? In any case, to reproduce, copy the following into a working directory. 3 revisions should be displayed by the log command at the end, but none are : echo 1 test.txt cvs add test.txt cvs commit -m test.txt echo 2 test.txt cvs commit -m test.txt echo 3 test.txt cvs commit -m test.txt cvs tag TEMP test.txt cvs log -rBEFORE::AFTER test.txt Output: cvs log: warning: no revision `PRIOR_TAG' in `...,v' RCS file: /.../test.txt,v Working file: test.txt head: 1.3 branch: locks: strict access list: symbolic names: TEMP: 1.3 keyword substitution: kv total revisions: 3; selected revisions: 0 description: = Best Regards, Matthew Herrmann Far Edge Technology http://www.faredge.com.au/ -Original Message- From: Matthew Herrmann [mailto:[EMAIL PROTECTED] Sent: Thursday, 27 November 2003 11:32 AM To: Larry Jones Subject: RE: cvs rlog -rTAG1::TAG2 doesn't handle newly added files thanks once again for your help Larry! -Original Message- From: Larry Jones [mailto:[EMAIL PROTECTED] Sent: Thursday, 27 November 2003 1:34 AM To: Matthew Herrmann Cc: [EMAIL PROTECTED] Subject: Re: cvs rlog -rTAG1::TAG2 doesn't handle newly added files Matthew Herrmann writes: I'm having problems with cvs rlog and -rTAG1::TAG2 not outputting changes for newly created tags. Update your server to the most recent release (1.11.9). -Larry Jones Do you think God lets you plea bargain? -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs rlog -rTAG1::TAG2 doesn't handle newly added files
Matthew Herrmann writes: I'm having problems with cvs rlog and -rTAG1::TAG2 not outputting changes for newly created tags. Update your server to the most recent release (1.11.9). -Larry Jones Do you think God lets you plea bargain? -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs rlog -rTAG1::TAG2 doesn't handle newly added files
Hi All, I'm having problems with cvs rlog and -rTAG1::TAG2 not outputting changes for newly created tags. I can't use cvs rdiff -s since I'm feeding the output into cvs2cl --xml. Versions: Client is 2.0.11 CVSNT (Windows 2000) Server is 1.11.2.1 (Linux) Here are steps to reproduce: 1. rtag module with TAG1. File Blah.txt doesn't exist yet. 2. Add Blah.txt to repository, make a couple of changes, Blah.txt now 1.3. 3. rtag module with TAG2. 4. Run cvs rlog -rTAG1::TAG2 module 5. The changes to Blah.txt will not appear because TAG1 didn't exist before. This seems inconsistent with behaviour of other parts of cvs, and certainly breaks my changeset roll-forward/roll-back scripts. To my understanding, the logic to fix this would be: - If TAG2 exists on file, but not TAG1, then act as if the file were tagged version before revision 1.1. Therefore, -rBEFORE::1.1 would return the changes for 1.1 for that file. I think that would work for branches too since there should at least be a phantom copy of the file if it was in the repository, but deleted. Does this sound right? TIA for any assistance, Matthew Herrmann Far Edge Technology http://www.faredge.com.au/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Strange behaviour with cvs rlog and branch tag
At 11:07 13/08/2003 +0200, you wrote: OK, so may be I do not use the right command to get what I want. All I need is to list files that will be checkout if I use the specified tag (ie the list of files that will be displayed when I checkout but without actually checkout them). That's what I get if I use the cvs rlog command with the simple tag. But how get the list of files of a tagged branch? Do I need to use another command? Thanks in advance Maybe cvs -qn checkout -rBRANCH ? -- Julien It should work but I reveive the following error: cvs [checkout aborted]: there is no version here; run 'cvs checkout' first I searched google but found no solution with this problem Olivier ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Strange behaviour with cvs rlog and branch tag
At 11:36 12/08/2003 -0400, you wrote: Olivier Imbrechts writes: When listing files tagged with a branch tag I only get directories while it works fine with simple tag. Am I missing something or is it a bug? There aren't any revisions actually on the branch yet (the root is not on the branch), which is why you're not getting any results. I don't think that's a bug, but it might be possible to convince me otherwise. OK, so may be I do not use the right command to get what I want. All I need is to list files that will be checkout if I use the specified tag (ie the list of files that will be displayed when I checkout but without actually checkout them). That's what I get if I use the cvs rlog command with the simple tag. But how get the list of files of a tagged branch? Do I need to use another command? Thanks in advance Olivier ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Strange behaviour with cvs rlog and branch tag
Olivier Imbrechts writes: When listing files tagged with a branch tag I only get directories while it works fine with simple tag. Am I missing something or is it a bug? There aren't any revisions actually on the branch yet (the root is not on the branch), which is why you're not getting any results. I don't think that's a bug, but it might be possible to convince me otherwise. -Larry Jones From now on, I'm devoting myself to the cultivation of interpersonal relationships. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Strange behaviour with cvs rlog and branch tag
On Tue, Aug 12, 2003 at 11:36:42AM -0400, Larry Jones wrote: Olivier Imbrechts writes: When listing files tagged with a branch tag I only get directories while it works fine with simple tag. There aren't any revisions actually on the branch yet (the root is not on the branch), which is why you're not getting any results. I don't think that's a bug, but it might be possible to convince me otherwise. It seems to me that the root is on the branch, in the sense that cvs up -rBRANCH will yield it (i.e. it's on the branch in the CVS sense, even if not in the RCS sense). However, I can see wanting to ask either question: - For which files has someone actually committed something to the branch? - Which files have branch tag X, i.e. which files will be in my sandbox if I do cvs update -rX? So it's hard to argue that either of the two behaviours is correct or a bug; either one could be what the user's looking for. It's the same difference as that between cvs log -rX:Y and -rX::Y. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: rlog: How to get log messages *after* one tag up to another tag
David Carson writes: Granted. I agree that the problem is not trivial. But, are you saying that it is not possible with CVS? No, I'm just saying that it's not trivial and that But rdiff does it! is completely irrelevant. -Larry Jones Kicking dust is the only part of this game we really like. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: rlog: How to get log messages *after* one tag up to another tag
[EMAIL PROTECTED] (Larry Jones) wrote in message news:[EMAIL PROTECTED]... David Carson writes: I'm sure there is some complication involved, but it is apparently possible. The cvs rdiff -rrevA -rrevB syntax handles this problem correctly, going from revA to revB even if from trunk to branch. As long as point A is an ancestor of point B, then there is only one way to get to B from A. But rdiff doesn't care whether A is an ancestor of B or not, it compares *any* two revisions. The complication is determining whether A is an ancestor of B, B is an ancestor of A, or neither is an ancestor of the other. Granted. I agree that the problem is not trivial. But, are you saying that it is not possible with CVS? I would reiterate my earlier assertion that a version control system must be able to perform this function to call itself fully functional. David ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
rlog: How to get log messages *after* one tag up to another tag
Unfortunately, by ISP does not carry gnu.cvs.help and google groups won't let me respond to this thread for some reason. So, I'm posting a new message that is really a continuation of this thread. Larry Jones wrote: Jim Doyle writes: Is there a chance the cvs log features recently added can be further extended to work across branches? To a user, I think 1.3, 1.3.2.1, 1.3.2.2, ... looks like a legal sequence that cvs log should be able to follow. Would it make sense to allow ranges A::B, where A precedes B on the same branch, *or* A::B' is itself a legal range, where B' is the origin of the branch B is on? Then the code could walk backwards from B, jumping to the branch origin of B while A has fewer numdots than B. Does this make sense when coming at it from the point of view of implementing CVS? Yes, I noticed that as a potential problem when I was adding the :: support, but I didn't worry about it too much since I don't recall anyone ever reporting it. Unfortunately, the code is full of It seems to me that one of the basic features of a version control system is the ability to retrieve the history of a file from point A to point B. It matters not that point A is on the trunk and point B is on a branch. We primarily work on branches, so we are suffering greatly as a result of this shortcoming. Every time we create a new branch, we tag the trunk so that we can do something like: cvs rlog -rroot-of-foo::branch-foo module/name/bar.c This should give me all revisions of bar.c that occurred on branch-foo. However, this is rejected with invalid branch or revision pair as discussed earlier. Please, please, consider this a problem that needs to be fixed. assumptions that the starting and ending revision numbers have the same number of dots, so there's a lot of rewriting to do. It's also not quite as simple as it might seem, since I believe that 1.2:4.5.6.7.8.9 should also be a valid range, no? (All revisions with a single dot are I'm sure there is some complication involved, but it is apparently possible. The cvs rdiff -rrevA -rrevB syntax handles this problem correctly, going from revA to revB even if from trunk to branch. As long as point A is an ancestor of point B, then there is only one way to get to B from A. Thanks, David ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: rlog: How to get log messages *after* one tag up to another tag
David Carson writes: I'm sure there is some complication involved, but it is apparently possible. The cvs rdiff -rrevA -rrevB syntax handles this problem correctly, going from revA to revB even if from trunk to branch. As long as point A is an ancestor of point B, then there is only one way to get to B from A. But rdiff doesn't care whether A is an ancestor of B or not, it compares *any* two revisions. The complication is determining whether A is an ancestor of B, B is an ancestor of A, or neither is an ancestor of the other. -Larry Jones My dreams are getting way too literal. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
rlog not supported
This is the Version of CVS running on our server: (CVS) 1.11 (client/server) And here is the error message: cvs [rlog aborted]: server does not support rlog Should we be upgrading to 1.11.1p1 ? Does that have rlog support? Thx. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: rlog not supported
Arcin Bozkurt - Archie writes: Should we be upgrading to 1.11.1p1 ? Does that have rlog support? Yes, rlog was added in 1.11.1. -Larry Jones I take it there's no qualifying exam to be a Dad. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: rlog
Duncan Sommerville writes: Is an rlog operation available (in the CVS sense), and if so from what version? You need CVS 1.11.1p1 or newer (note that there are no newer releases yet, just the development version). It works just like log except it takes module/file names ala checkout and doesn't require a working directory. -Larry Jones That's one of the remarkable things about life. It's never so bad that it can't get worse. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvs rlog -l
I should have mentioned that this happens with a local repository. Jerry From: Stephen Rasku [mailto:[EMAIL PROTECTED]] Sent: Friday, May 11, 2001 1:00 PM Jerry Nairn wrote: On a tangent, I find that cvs rlog -l module is recursive when I am seeing the same thing on a Solaris 7 pserver setup. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs rlog
Has the patch described in the following thread been implemented in cvs 1.11? Are there any plans to include it in a future version of CVS? http://mail.gnu.org/pipermail/info-cvs/2000-November/thread.html#10972 -- Stephen Rasku E-mail: [EMAIL PROTECTED] Senior Software EngineerWeb:http://www.pop-star.net/ TGI Technologies ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [PATCH] cvs list and cvs rlog
[ On Sunday, November 12, 2000 at 18:08:01 (-), Alastair J. Houghton wrote: ] Subject: [PATCH] cvs list and cvs rlog "cvs list" is a very useful command, but you still can't see all of the information that might be useful; therefore I created "cvs rlog" (replacing the old deprecated synonym for "log"), which displays log entries without a working directory. Doubtless a flame war will now ensue over whether this is an appropriate name (I think it is, because it goes with the convention already established for "rtag" - on the other hand, "rlog" used to mean something slightly different, but the warning has been around at least since 1.10 so no-one should be using "rlog" now). Oh, VERY cool! THANK YOU! I've been wanting to do exactly this for the better part of a decade! :-) I think one or two variants of what you've posted have been available for some time; and I did make my own version work, but not in client/server mode. The paranoia about tromping on the "rlog" synonym was supposed to have been tromped out sometime back near version 1.5, so by now there should even be any dust left from it. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
[PATCH] cvs list and cvs rlog
On the 16th of last month, Peter Bowen posted a patch on the
info-cvs-request list that provided a new command, "cvs list".
Unfortunately, that patch has a bug (try "cvs ls -a CVSROOT"
on a new repository).
"cvs list" is a very useful command, but you still can't see all
of the information that might be useful; therefore I created
"cvs rlog" (replacing the old deprecated synonym for "log"), which
displays log entries without a working directory. Doubtless a flame
war will now ensue over whether this is an appropriate name (I think
it is, because it goes with the convention already established for
"rtag" - on the other hand, "rlog" used to mean something slightly
different, but the warning has been around at least since 1.10 so
no-one should be using "rlog" now).
Note that:
1. I'm not on the development list, nor do I intend to
subscribe to it; so any replies had better go to my mail
address...
2. I haven't tested the client/server functionality; I *think*
it does the right thing, but as I'm on WinNT it's harder
to test this than it would be e.g. on UNIX.
Hope this proves useful,
Alastair.
p.s. The following things are attached:
1. cvs-rlog.diff; this patch provides the "cvs rlog" command.
2. list.diff/list.c; a fixed version of Peter Bowen's "cvs list".
list.c
Index: cvs.h
===
RCS file: /home2/cvsroot/ccvs/src/cvs.h,v
retrieving revision 1.206
diff -u -r1.206 cvs.h
--- cvs.h 2000/10/12 15:33:21 1.206
+++ cvs.h 2000/10/16 21:40:41
@@ -314,7 +314,7 @@
/* The type of request that is being done in do_module() */
enum mtype
{
-CHECKOUT, TAG, PATCH, EXPORT
+CHECKOUT, TAG, PATCH, EXPORT, CVSLIST
};
/*
@@ -856,6 +856,7 @@
extern int cvsstatus PROTO((int argc, char **argv));
extern int cvstag PROTO((int argc, char **argv));
extern int version PROTO((int argc, char **argv));
+extern int cvslist PROTO((int argc, char **argv));
extern unsigned long int lookup_command_attribute PROTO((char *));
Index: main.c
===
RCS file: /home2/cvsroot/ccvs/src/main.c,v
retrieving revision 1.154
diff -u -r1.154 main.c
--- main.c 2000/10/11 16:17:53 1.154
+++ main.c 2000/10/16 21:40:41
@@ -114,6 +114,7 @@
#if defined (HAVE_KERBEROS) defined (SERVER_SUPPORT)
{ "kserver", NULL, NULL,server }, /* placeholder */
#endif
+{ "list","ls", NULL,cvslist },
{ "log", "lo", "rlog", cvslog },
#ifdef AUTH_CLIENT_SUPPORT
{ "login","logon","lgn", login },
@@ -329,6 +330,7 @@
something doesn't use the WD. */
if ((strcmp (cmd_name, "checkout") != 0)
(strcmp (cmd_name, "init") != 0)
+(strcmp (cmd_name, "list") != 0)
(strcmp (cmd_name, "login") != 0)
(strcmp (cmd_name, "logout") != 0)
(strcmp (cmd_name, "rdiff") != 0)
@@ -350,6 +352,7 @@
(strcmp (cmd_name, "editors") != 0)
(strcmp (cmd_name, "export") != 0)
(strcmp (cmd_name, "history") != 0)
+(strcmp (cmd_name, "list") != 0)
(strcmp (cmd_name, "log") != 0)
(strcmp (cmd_name, "noop") != 0)
(strcmp (cmd_name, "watchers") != 0)
diff -w -r -u orig/cvs-1.11/src/cvs.h cvs-1.11/src/cvs.h
--- orig/cvs-1.11/src/cvs.h Sat Jul 8 21:57:22 2000
+++ cvs-1.11/src/cvs.h Sun Nov 12 17:39:25 2000
@@ -314,7 +314,7 @@
/* The type of request that is being done in do_module() */
enum mtype
{
-CHECKOUT, TAG, PATCH, EXPORT
+CHECKOUT, TAG, PATCH, EXPORT, CVSRLOG
};
/*
@@ -857,6 +857,7 @@
extern int cvsstatus PROTO((int argc, char **argv));
extern int cvstag PROTO((int argc, char **argv));
extern int version PROTO((int argc, char **argv));
+extern int cvsrlog PROTO((int argc, char **argv));
extern unsigned long int lookup_command_attribute PROTO((char *));
diff -w -r -u orig/cvs-1.11/src/log.c cvs-1.11/src/log.c
--- orig/cvs-1.11/src/log.c Thu Jun 22 00:28:38 2000
+++ cvs-1.11/src/log.c Sun Nov 12 17:15:05 2000
@@ -105,6 +105,10 @@
RCSNode *rcs;
};
+static int rlog_list_proc PROTO ((int argc, char **argv, char *xwhere,
+ char *mwhere, char *mfile, int shorten,
+ int local_specified, char *mname,
+ char *msg));
static Dtype log_dirproc PROTO ((void *callerdat, char *dir,
char *repository, char *update_dir,
List *entries));
@@ -149,6 +153,25 @@
NULL
};
+static const char *cons
RE: [PATCH] cvs list and cvs rlog
Oops. Found a security hole (not a major one - but it does let others
explore the directory structure outside your repository...). Try for
example
cvs list ../usr
The solution is of course to add the lines
/* Check the repository path */
if (pathname_levels (argv[0]) 0)
{
error (0, 0, "`..'-relative repositories are not supported.");
error (1, 0, "illegal source repository");
}
to the very beginning of "list_proc" in "list.c" and
"rlog_list_proc" (Why did I call it this?! Consider it renamed to
"rlog_proc") in "log.c".
Regards,
Alastair.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
RE: bug in rlog?
From: Lukas Gruetzmacher [EMAIL PROTECTED]
Subject: bug in rlog?
Date: Thu, 30 Mar 2000 00:32:35 +0900 (JST)
| I think I've found a bug in rlog - May be is a feature... (I hope a talk
| about a rcs tool is welcome on this list.)
This is specification of RCS file. See man page rcsfile(5).
The following is definition of state attribute.
state {id};
id ::= {num} idchar {idchar | num}*
num ::= {digit | .}+
digit ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
idchar ::= any visible graphic character except special
value of state is optional.
rcs -s can not make id empty. cvs admin -s can.
cvs log will dump core. rlog display `state: (null);'.
| rlog can't handle rcs files with a dot in the state like:
| date2000.03.14.14.25.13;author lukasg; state 0.2.1;
`0.2.1' is invalid, but `0.2.1-state' is valid.
CVS should check validity like RCS.
% rcs -s'1.2':1.1 FILE
rcs: invalid identifier `1.2'
rcs aborted
%
--
KOIE Hidetaka [EMAIL PROTECTED]
