CVS log between revs - filter extra info
Hi, I have been trying to get a cvs log between revs that only shows log messages for what has changed between revs. I've tried cvs log -rrev1:rev2 and -rrev1::rev2. Both of which either show way too much info or not enough. Where extra data is logs for files that have not changed. And not enough data means that some files are excluded (because of the nature of : and ::). My hunt for an answer only turns up some references to the problem not the solution (e.g. http://lists.gnu.org/archive/html/info-cvs/2001-05/msg00190.html). So, is this a valid solution, or am I missing something important: - Get all changed files via cvs diff -rrev1 -rrev2 module - Get the log for all files gathered above via cvs log -rrev1::rev2 The most important thing is to be sure that: a) all logs of changes made from the end of rev1 to and including rev2's changes are included. b) no log given for files that have not changed from rev1 to rev2. The purpose of all this is to provide an 'at a glance' web page view (via ant's changeLog task) for managers. So, will the above do? I am mainly concerned that the log report will be missing some logs. Should the logs match the diffs? Regards, --Russ ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS log between revs - filter extra info
Russ Sherk writes: I have been trying to get a cvs log between revs that only shows log messages for what has changed between revs. I've tried cvs log -rrev1:rev2 and -rrev1::rev2. Both of which either show way too much info or not enough. Where extra data is logs for files that have not changed. And not enough data means that some files are excluded (because of the nature of : and ::). cvs log -S -rrev1::rev2 should do exactly what you want, provided you're using a reasonably recent release of CVS. If not, please be specific about what's wrong, preferably with actual examples. -Larry Jones Things are never quite as scary when you've got a best friend. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
cvs log: incorrect usage?
If my repository is /usr/local/cvs, am I not supposed to be able to do this: cvs log /usr/local/cvs/project/file.py,v I get the *PANIC* administration files missing error every time. There is a CVS directory for that project. This command doesn't work on two different machines in three different repositories. What gives? Now, if the cvs log command is only supposed to be used in checked out sandboxes, fine. What can I do then to be able to parse repository files for tags? Thanks for your help, Bob PS cvs history on the same pathname works just fine. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs log: incorrect usage?
coach24 writes: If my repository is /usr/local/cvs, am I not supposed to be able to do this: cvs log /usr/local/cvs/project/file.py,v No, log is for use in a working directory; you want rlog. Most CVS commands come in pairs -- foo and rfoo. foo is for use in a working directory, rfoo is for direct access to the repository. And you don't specify the entire path to the repository file, you just specify the path relative to your $CVSROOT. You also specify the working file name, not the RCS file name. So, assuming your $CVSROOT is correctly set to /usr/local/cvs, the command you want is: cvs rlog project/file.py -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 Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs log: incorrect usage?
coach24 wrote: If my repository is /usr/local/cvs, am I not supposed to be able to do this: cvs log /usr/local/cvs/project/file.py,v I get the *PANIC* administration files missing error every time. There is a CVS directory for that project. This command doesn't work on two different machines in three different repositories. What gives? ClueX4 yourself until you no longer feel the need to use commands directly on the repository files after you set it up, with _one_ exception the backup routine. :) Now, if the cvs log command is only supposed to be used in checked out sandboxes, fine. This is a true statement. What can I do then to be able to parse repository files for tags? In a sandbox: cvs log file.py |grep -A25 symbolic names: everything between symbolic names: and keyword substitution: is a relationship between a tag and a file revision. Does this help? Thanks for your help, Bob PS cvs history on the same pathname works just fine. um, don't do that either. :) -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs log: incorrect usage?
Larry, I get a message about rlog being deprecated and it says no such directory anyway. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs log: incorrect usage?
Bob McCallister wrote: But what if I want to know what tags are available for a given project? We have a librarian who checks out tagged versions of projects to their production location. That librarian has no idea who is working on the project and therefore doesn't know where the working copies reside. Are you saying the librarian should have to check out a copy just to get the tags? 1) You already indicated the librarian HAS a checked out copy as part of thier job. :) the log command IIRC lists ALL revisions and tags, not just the one that was used to checkout a version. 2) as larry mentioned rlog (on current versions) will work without a checked out copy. 3) how is your libriarian to know what one they should be checking out anyway? Surely your process includes passing along the current production tag, correct? coach24 wrote: If my repository is /usr/local/cvs, am I not supposed to be able to do this: cvs log /usr/local/cvs/project/file.py,v I get the *PANIC* administration files missing error every time. There is a CVS directory for that project. This command doesn't work on two different machines in three different repositories. What gives? ClueX4 yourself until you no longer feel the need to use commands directly on the repository files after you set it up, with _one_ exception the backup routine. :) Now, if the cvs log command is only supposed to be used in checked out sandboxes, fine. This is a true statement. What can I do then to be able to parse repository files for tags? In a sandbox: cvs log file.py |grep -A25 symbolic names: everything between symbolic names: and keyword substitution: is a relationship between a tag and a file revision. Does this help? Thanks for your help, Bob PS cvs history on the same pathname works just fine. um, don't do that either. :) -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter __ This e-mail has been scanned by MCI Managed Email Content Service, using Skeptic(tm) technology powered by MessageLabs. For more information on MCI's Managed Email Content Service, visit http://www.mci.com. __ -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs log: incorrect usage?
coach24 writes: I get a message about rlog being deprecated and it says no such directory anyway. Then you have an ancient version of CVS -- you need to update. -Larry Jones I don't think that question was very hypothetical at all. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs log: incorrect usage?
Bob McCallister wrote: You misunderstood me. The librarian is presented with a screen that lists all the projects. He clicks on a project and is presented with a list of tags (in theory). He then chooses which tag and *then* the project is checked out to its target directory. I suppose there are processes in place to help him choose the correct tag from the list. As for cvs rlog - I get a deprecated warning (use log) and I got an error that the directory was not found. My $CVSROOT was set accordingly. try `cvs --version` the rlog command is deprecated was fixed/changed between cvs-1.11 and cvs-1.11.1, it really is time for you to upgrade, there have been numerous fixes including security since then. Bob McCallister wrote: But what if I want to know what tags are available for a given project? We have a librarian who checks out tagged versions of projects to their production location. That librarian has no idea who is working on the project and therefore doesn't know where the working copies reside. Are you saying the librarian should have to check out a copy just to get the tags? 1) You already indicated the librarian HAS a checked out copy as part of thier job. :) the log command IIRC lists ALL revisions and tags, not just the one that was used to checkout a version. 2) as larry mentioned rlog (on current versions) will work without a checked out copy. 3) how is your libriarian to know what one they should be checking out anyway? Surely your process includes passing along the current production tag, correct? SNIP -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs log: incorrect usage?
Ok, upgrading and using cvs rlog solved the problem. Thanks for everyone's help. Bob ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Equivalent to cvs log -rBASE::HEAD?
Jim Searle writes:
I found this question in the archives, but never saw an answer. Is there a
way to get 'BASE' to work with 'cvs log'?
Yes, by fixing the code, which I just did. :-)
The fix will be in the next releases. If you just can't wait, here's a
patch (for the stable [1.11] branch):
Index: log.c
===
RCS file: /cvs/ccvs/src/log.c,v
retrieving revision 1.79.4.12
retrieving revision 1.79.4.14
diff -u -r1.79.4.12 -r1.79.4.14
--- log.c 29 Jan 2005 18:39:50 - 1.79.4.12
+++ log.c 1 Feb 2005 19:09:07 - 1.79.4.14
@@ -1,6 +1,11 @@
/*
- * Copyright (c) 1992, Brian Berliner and Jeff Polk
- * Copyright (c) 1989-1992, Brian Berliner
+ * Copyright (C) 1986-2005 The Free Software Foundation, Inc.
+ *
+ * Portions Copyright (C) 1998-2005 Derek Price, Ximbiot http://ximbiot.com,
+ * and others.
+ *
+ * Portions Copyright (C) 1992, Brian Berliner and Jeff Polk
+ * Portions Copyright (C) 1989-1992, Brian Berliner
*
* You may distribute under the terms of the GNU General Public License as
* specified in the README file that comes with the CVS source distribution.
@@ -123,7 +128,7 @@
static struct option_revlist *log_parse_revlist PROTO ((const char *));
static void log_parse_date PROTO ((struct log_data *, const char *));
static void log_parse_list PROTO ((List **, const char *));
-static struct revlist *log_expand_revlist PROTO ((RCSNode *,
+static struct revlist *log_expand_revlist PROTO ((RCSNode *, char *,
struct option_revlist *,
int));
static void log_free_revlist PROTO ((struct revlist *));
@@ -810,21 +815,30 @@
{
struct log_data *log_data = (struct log_data *) callerdat;
Node *p;
+char *baserev;
int selrev = -1;
RCSNode *rcsfile;
char buf[50];
struct revlist *revlist = NULL;
struct log_data_and_rcs log_data_and_rcs;
-if ((rcsfile = finfo-rcs) == NULL)
+rcsfile = finfo-rcs;
+p = findnode (finfo-entries, finfo-file);
+if (p != NULL)
+{
+ Entnode *e = p-data;
+ baserev = e-version;
+ if (baserev[0] == '-') ++baserev;
+}
+else
+ baserev = NULL;
+
+if (rcsfile == NULL)
{
/* no rcs file. What *do* we know about this file? */
- p = findnode (finfo-entries, finfo-file);
- if (p != NULL)
+ if (baserev != NULL)
{
- Entnode *e = p-data;
-
- if (e-version[0] == '0' e-version[1] == '\0')
+ if (baserev[0] == '0' baserev[1] == '\0')
{
if (!really_quiet)
error (0, 0, %s has been added, but not committed,
@@ -847,7 +861,7 @@
/* Turn any symbolic revisions in the revision list into numeric
revisions. */
- revlist = log_expand_revlist (rcsfile, log_data-revlist,
+ revlist = log_expand_revlist (rcsfile, baserev, log_data-revlist,
log_data-default_branch);
if (log_data-sup_header
|| (!log_data-header !log_data-long_header))
@@ -1037,8 +1051,9 @@
* Expand any symbolic revisions.
*/
static struct revlist *
-log_expand_revlist (rcs, revlist, default_branch)
+log_expand_revlist (rcs, baserev, revlist, default_branch)
RCSNode *rcs;
+char *baserev;
struct option_revlist *revlist;
int default_branch;
{
@@ -1099,7 +1114,9 @@
nr-first = xstrdup (r-first);
else
{
- if (RCS_nodeisbranch (rcs, r-first))
+ if (baserev strcmp (r-first, TAG_BASE) == 0)
+ nr-first = xstrdup (baserev);
+ else if (RCS_nodeisbranch (rcs, r-first))
nr-first = RCS_whatbranch (rcs, r-first);
else
nr-first = RCS_gettag (rcs, r-first, 1, (int *) NULL);
@@ -1117,7 +1134,9 @@
nr-last = xstrdup (r-last);
else
{
- if (RCS_nodeisbranch (rcs, r-last))
+ if (baserev strcmp (r-last, TAG_BASE) == 0)
+ nr-last = xstrdup (baserev);
+ else if (RCS_nodeisbranch (rcs, r-last))
nr-last = RCS_whatbranch (rcs, r-last);
else
nr-last = RCS_gettag (rcs, r-last, 1, (int *) NULL);
-Larry Jones
There's never enough time to do all the nothing you want. -- Calvin
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Equivalent to cvs log -rBASE::HEAD?
I found this question in the archives, but never saw an answer. Is there a way to get 'BASE' to work with 'cvs log'? Thanks, jim From: Slawomir Nowaczyk Subject:Equivalent to cvs log -rBASE::HEAD? Date: Wed, 29 Sep 2004 17:57:49 +0200 Hello, I would like to see cvs log messages for all the files and revisions which will be updated by next cvs update command -- to get an idea as to what has been changed. Ideally, I would like to do cvs log -rBASE::HEAD But log -r switch only accepts revisions, not tags (according to the documentation). Somehow, the HEAD is working, but BASE is not (I get no revision `BASE' in ... error message). I can imagine checking each file's currently checked out revision number and calling cvs log once per file... but is there an easier solution? Thanks in advice for any advices. -- Best wishes, Slawomir Nowaczyk Grossman's Law: Complex problems have simple, easy-to-understand, wrong answers. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: using cvs log like cvs log -d 24 hours ago
Hi, cvs log -S -d 24 hours ago works fine for me. It gave me the log of changes made 24 hours ago on the CVS repository. Thank you Pradeep Kumar T Todd Denniston [EMAIL PROTECTED] To: [EMAIL PROTECTED] .navy.mil cc: info-cvs@gnu.org Sent by:Subject: Re: using cvs log like cvs log -d 24 hours ago [EMAIL PROTECTED] il 25-01-05 09:02 PM [EMAIL PROTECTED] wrote: Hi, i need to get the CVS log entries for entries made in the last 24 hours! i tried using cvs log like cvs log -d 24 hours ago it doesnt work. Any alternative? cvs log does not work as I expect, but it can be made to give what you want. try cvs log -S -d 24 hours ago the -S Do not print name/header if no revisions selected. and the indicates I want changes after the specified date, and we leave the up to date unspecified so cvs fills it in with NOW. cvs log --help is a little confusing, I had to go to an old email I answered to get this trick. -d datesA semicolon-separated list of dates (D1D2 for range, D for latest before). perhaps a better output would be -d datesA semicolon-separated list of dates, or D1D2 for a date range, or D for changes since D, or D Select the single, latest revision dated D or earlier. Thanks and Regards. Pradeep Kumar T -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter This email and any attachments have been scanned for known viruses using multiple scanners. We believe that this email and any attachments are virus free, however the recipient must take full responsibility for virus checking. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the intended named recipient of this email then you should not copy it or use it for any purpose, nor disclose its contents to any other person. You should contact Misys International Financial Systems so that we can take appropriate action at no cost to yourself. Misys International Financial Systems is part of Misys Banking and Securities Division, a member of Misys Group of Companies. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: using cvs log like cvs log -d 24 hours ago
Hi Surya, 24 hours ago is a time constraint, not a tag. If u can tell me what error u get maybe(as i am a newbie too) i can help . Regards Pradeep Kumar T Surya Prakash To: [EMAIL PROTECTED] [EMAIL PROTECTED] cc: mic.co.in Subject: Re: using cvs log like cvs log -d 24 hours ago 27-01-05 05:08 PM Hi pradeep you said that cvs log -S -d 24 hours ago fine I need samll qurey can you tell me that 24hours ago is name of the tag what you want to go for log or that is time constraint .. I have Treind this but i am not able to get that .. giving some error.. Thanks in advance . surya - Original Message - From: [EMAIL PROTECTED] To: info-cvs@gnu.org Sent: Thursday, January 27, 2005 3:05 PM Subject: Re: using cvs log like cvs log -d 24 hours ago Hi, cvs log -S -d 24 hours ago works fine for me. It gave me the log of changes made 24 hours ago on the CVS repository. Thank you Pradeep Kumar T Todd Denniston [EMAIL PROTECTED] To: [EMAIL PROTECTED] .navy.mil cc: info-cvs@gnu.org Sent by:Subject: Re: using cvs log like cvs log -d 24 hours ago [EMAIL PROTECTED] il 25-01-05 09:02 PM [EMAIL PROTECTED] wrote: Hi, i need to get the CVS log entries for entries made in the last 24 hours! i tried using cvs log like cvs log -d 24 hours ago it doesnt work. Any alternative? cvs log does not work as I expect, but it can be made to give what you want. try cvs log -S -d 24 hours ago the -S Do not print name/header if no revisions selected. and the indicates I want changes after the specified date, and we leave the up to date unspecified so cvs fills it in with NOW. cvs log --help is a little confusing, I had to go to an old email I answered to get this trick. -d datesA semicolon-separated list of dates (D1D2 for range, D for latest before). perhaps a better output would be -d datesA semicolon-separated list of dates, or D1D2 for a date range, or D for changes since D, or D Select the single, latest revision dated D or earlier. Thanks and Regards. Pradeep Kumar T -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter -- -- This email and any attachments have been scanned for known viruses using multiple scanners. We believe that this email and any attachments are virus free, however the recipient must take full responsibility for virus checking. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the intended named recipient of this email then you should not copy it or use it for any purpose, nor disclose its contents to any other person. You should contact Misys International Financial Systems so that we can take appropriate action at no cost to yourself. Misys International Financial Systems is part of Misys Banking and Securities Division, a member of Misys Group of Companies. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
using cvs log like cvs log -d 24 hours ago
Hi, i need to get the CVS log entries for entries made in the last 24 hours! i tried using cvs log like cvs log -d 24 hours ago it doesnt work. Any alternative? Thanks and Regards. Pradeep Kumar T This email and any attachments have been scanned for known viruses using multiple scanners. We believe that this email and any attachments are virus free, however the recipient must take full responsibility for virus checking. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the intended named recipient of this email then you should not copy it or use it for any purpose, nor disclose its contents to any other person. You should contact Misys International Financial Systems so that we can take appropriate action at no cost to yourself. Misys International Financial Systems is part of Misys Banking and Securities Division, a member of Misys Group of Companies. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: using cvs log like cvs log -d 24 hours ago
[EMAIL PROTECTED] wrote: Hi, i need to get the CVS log entries for entries made in the last 24 hours! i tried using cvs log like cvs log -d 24 hours ago it doesnt work. Any alternative? cvs log does not work as I expect, but it can be made to give what you want. try cvs log -S -d 24 hours ago the -S Do not print name/header if no revisions selected. and the indicates I want changes after the specified date, and we leave the up to date unspecified so cvs fills it in with NOW. cvs log --help is a little confusing, I had to go to an old email I answered to get this trick. -d datesA semicolon-separated list of dates (D1D2 for range, D for latest before). perhaps a better output would be -d datesA semicolon-separated list of dates, or D1D2 for a date range, or D for changes since D, or D Select the single, latest revision dated D or earlier. Thanks and Regards. Pradeep Kumar T -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Problem with cvs log -d
I'm running cvs version 1.11.17 on a Sun E250 Solaris 9 and can't seem to get logs by date working. $ cvs --version Concurrent Versions System (CVS) 1.11.17 (client/server) If I issue the comand $ cvs log -d =20041120 I am returned with log information for all files in the directory. Here is a cut and paste of the CVS/Entries file from the directory in question: /VlprepcCommon.h/2.4/Fri Nov 19 14:10:58 2004// /VlprepcFileMgr.cpp/2.3/Wed Mar 22 22:57:01 2000// /VlprepcFileMgr.h/2.1/Fri Feb 6 19:35:10 1998// /Vlprepcplus.cpp/2.7/Fri Nov 19 14:07:41 2004// /Vlprepcplus.h/2.1/Fri Feb 6 19:35:14 1998// /fwmemory.cpp/1.2/Thu Nov 5 14:22:34 1998// /string_toupper.cpp/2.1/Fri Feb 6 19:34:37 1998// /vl_common.cpp/2.10/Fri Jul 21 21:41:18 2000// /vlpsos.cpp/2.1/Fri Feb 6 19:34:39 1998// /vlq_send.cpp/2.5/Fri Nov 19 14:20:32 2004// /vlprepc.cpp/2.17/Wed Dec 1 21:43:10 2004// D Shouldn't I only get log information for the file vlprepc.cpp? The machine date is correct as are the time stamps of all my files in the sandbox. My TZ environment variable is set to US/Central. I've done dozens of web searches and can't find any similar problems to mine. Thanks for any help. -- Scott Watters [EMAIL PROTECTED] ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with cvs log -d
Scott Watters writes: $ cvs log -d =20041120 I am returned with log information for all files in the directory. Correct. The -d option only affects which log messages get displayed, you still get headers for all the files. If you don't want the extra headers, you need the -S option, too. -Larry Jones Aw Mom, you act like I'm not even wearing a bungee cord! -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with cvs log -d
DOH!! I've been staring at the mole book and man page for hours. I have no idea how I glossed over that option. Sorry for the waste of bandwidth. Scott On Mon, 2005-01-10 at 17:05 -0500, Larry Jones wrote: Scott Watters writes: $ cvs log -d =20041120 I am returned with log information for all files in the directory. Correct. The -d option only affects which log messages get displayed, you still get headers for all the files. If you don't want the extra headers, you need the -S option, too. -Larry Jones Aw Mom, you act like I'm not even wearing a bungee cord! -- Calvin -- Scott Watters [EMAIL PROTECTED] ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Equivalent to cvs log -rBASE::HEAD?
[ On Tuesday, October 5, 2004 at 18:41:59 (+0200), Slawomir Nowaczyk wrote: ] Subject: Re: Equivalent to cvs log -rBASE::HEAD? Note if it did work, then you would only need cvs log -rBASE::. Specifying HEAD would be meaningless (and perhaps also misleading since it is defined as simply the latest rev in the repository without respect to branch). I think it doesn't work becasue the 'cvs log -rREV::' magic only works for real (non-branch) tags -- or at least that's what it seems. Unfortunately cvs tag -r BASE my-special-private-BASE . doesn't work either. BASE (and HEAD) are poorly implemented (i.e. not uniformly implemented) and they are not extensively tested either. -- Greg A. Woods +1 416 218-0098 VE3TCPRoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Equivalent to cvs log -rBASE::HEAD?
On Fri, 01 Oct 2004 12:21:04 -0700 David Schnepper [EMAIL PROTECTED] wrote: # Did you ever get an answer to this? This is precisely the problem I # hit my head against every few months. I wound up writing a python # script that figures out the differences between top-of-branch and # top-of-tree. It would be so much simplier if there were a pseudo # tag meaning top-of-tree Nope... no answer at all. I was just going to repeat the question... well, I am going to do it right now :-) I am aware that lack of answer usually means nobody knows the answer, but I refuse to accept that possibility. So: I know the code I have in my workspace. But then I want to make cvs update. I would like to know, however, what is going to change - and not just filenames, but the log entries... for all the commits which happened between my last update and now. Something like cvs log -rBASE::HEAD looks perfect, and has only one single flaw: doesn't work. Any idea how else could I accomplish what I want? -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) Ever stopped to think, and forgot to start again? ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Equivalent to cvs log -rBASE::HEAD?
Hello, * On Tue, Oct 05, 2004 at 12:52:40PM +0200 Slawomir Nowaczyk wrote: I know the code I have in my workspace. But then I want to make cvs update. I would like to know, however, what is going to change - and not just filenames, but the log entries... for all the commits which happened between my last update and now. Something like cvs log -rBASE::HEAD looks perfect, and has only one single flaw: doesn't work. Well, what about cvs diff -uN -r HEAD? I have not tested if it works at all, and it would not give you the log but the complete diff, but it might be a partial solution to your problem? Regards, Spiro. -- Spiro R. Trikaliotis http://www.trikaliotis.net/ http://www.viceteam.org/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Equivalent to cvs log -rBASE::HEAD?
Slawomir == Slawomir Nowaczyk [EMAIL PROTECTED] writes: Slawomir I know the code I have in my workspace. But then I want to make Slawomir cvs update. I would like to know, however, what is going to Slawomir change - and not just filenames, but the log entries... for all the Slawomir commits which happened between my last update and now. Slawomir Something like cvs log -rBASE::HEAD looks perfect, and has only Slawomir one single flaw: doesn't work. Slawomir Any idea how else could I accomplish what I want? If you are interested, I could help you write a Perl script using LibCVS. To start, download the Perl VCS::LibCVS through CPAN, or from the website: libcvs.cvshome.org. Alex -- http://libcvs.cvshome.org/Access CVS through a library. PGP: ID: 0x23DC453B FPR: 42D0 66C2 9FF8 553A 373A B819 4C34 93BA 23DC 453B The purpose of the minutes is not to record events, it is to protect people. -- Sir Humphrey Appleby ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Equivalent to cvs log -rBASE::HEAD?
On Tue, 05 Oct 2004 13:27:36 +0200 Spiro Trikaliotis [EMAIL PROTECTED] wrote: # Well, what about cvs diff -uN -r HEAD? I have not tested if it # works at all, and it would not give you the log but the complete # diff, but it might be a partial solution to your problem? Yes, I can make diff to work... which is a partial solution for my problem, however, not exactly satisfactory :-( -- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] ) There are more than 1,000 chemicals in a cup of coffee. Of these, only 26 have been tested, and half caused cancer in rats. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Equivalent to cvs log -rBASE::HEAD?
Hello, I would like to see cvs log messages for all the files and revisions which will be updated by next cvs update command -- to get an idea as to what has been changed. Ideally, I would like to do cvs log -rBASE::HEAD But log -r switch only accepts revisions, not tags (according to the documentation). Somehow, the HEAD is working, but BASE is not (I get no revision `BASE' in ... error message). I can imagine checking each file's currently checked out revision number and calling cvs log once per file... but is there an easier solution? Thanks in advice for any advices. -- Best wishes, Slawomir Nowaczyk Grossman's Law: Complex problems have simple, easy-to-understand, wrong answers. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Weird characters in cvs log output
Hi, when I work with different WIN Clients I get weird characters when checking the history cvs log file ÷-02 14:11:45 +; author: xx; state: Exp; Thats leads to problem with Clients like WinCVS or tortiose so that they could not determine the Date correct. The same on a UNIX System displays everything correct. cvs Server 1.12.9 on debian/sarge Any Hint? TIA, Georg ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Weird characters in cvs log output
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Georg,
Georg Bischof [EMAIL PROTECTED] writes:
when I work with different WIN Clients I get weird characters when
checking the history
cvs log file
-02 14:11:45 +; author: xx; state: Exp;
Thats leads to problem with Clients like WinCVS or tortiose so that
they could not determine the Date correct.
The same on a UNIX System displays everything correct.
cvs Server 1.12.9 on debian/sarge
Any Hint?
As of cvs 1.12.9, the server will be printing the 'cvs log' time in
ISO 8601 format like this:
date: 2004-07-09 14:32:53 +; author: mdb; state: Exp;
or (if the client supports display in local time) this:
date: 2004-07-09 07:32:53 -0700; author: mdb; state: Exp;
(if you happen to be in the UTC=0700 timezone)
instead of the older format which would look like this:
date: 2004/07/09 14:32:53; author: mdb; state: Exp;
Hmmm... There may be a bug in cvs 1.12.9 in that it will never actually
use a timezone other than UTC right now. A possible (untested) patch is
given after my .signature for this to hopefully make the code match the
comments... Derek? Is this what you intended the code to do?
I know that CVSNT-2.0.46 (released 2004-06-26) does not yet support
conversion of date tagged MT data to localtime, so I would have
expected the clients to just display the string without messing with the
format.
-- Mark
ChangeLog:
2004-07-09 Mark D. Baushke [EMAIL PROTECTED]
* main.c (format_time_t): Use localtime() instead of gmtime() to
display log time in a non-UTC (+) format to match source
comment.
Index: main.c
===
RCS file: /cvs/ccvs/src/main.c,v
retrieving revision 1.212
diff -u -p -r1.212 main.c
- --- main.c29 May 2004 05:20:01 - 1.212
+++ main.c 9 Jul 2004 15:08:12 -
@@ -1219,7 +1219,7 @@ format_time_t (time_t unixtime)
{
static char buf[sizeof (-mm-dd HH:MM:SS -HHMM)];
/* Convert to a time in the local time zone. */
- -struct tm ltm = *(gmtime (unixtime));
+struct tm ltm = *(localtime (unixtime));
if (my_strftime (buf, sizeof (buf), %Y-%m-%d %H:%M:%S %z, ltm) == 0)
return NULL;
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFA7raS3x41pRYZE/gRAjxOAJ4z6uMExGHwSEp84n3yAAtcKYee6QCg4eEc
FLdaYb2oAe6OiPuo+KmcHBk=
=iKVI
-END PGP SIGNATURE-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs
cvs [log aborted]: unrecognized operation error
Hi, I have a file that I'm getting an abort from cvs log on in my repository. $ cvs log appspack/oracle/ig/modules/ar/install/sql/obtig_ar_filter_pb.sql cvs [log aborted]: unrecognized operation '\x73' in /export/cvs/prodops/appspack/oracle/ig/modules/ar/install/sql/obtig_ar_f ilter_pb.sql,v What's the best way to go about resolving this error? I've tried to find problems directly with the RCS file itself but I've been unable to find anything wrong with it and I'm afraid that I'm missing something obvious. Suggestions? Carter. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs [log aborted]: unrecognized operation error
Carter Thompson writes: What's the best way to go about resolving this error? I've tried to find problems directly with the RCS file itself but I've been unable to find anything wrong with it and I'm afraid that I'm missing something obvious. That error does, indeed, mean that the RCS file has been corrupted. I strongly suggest that you run the contrib/check_cvs script to check for any other files in your repository that have also been corrupted. There are no good ways to resolve the problem. Your best bet is to find a recent backup (that isn't also corrupted) that you can restore and then redo any subsequent changes. If the damage isn't too severe, you may be able to fix it by hand, but as you've discovered, that isn't an easy process (you may want to see if RCS will give you any more information about exactly were the problem lies). You need to find out what caused the corruption and make sure it doesn't happen again. The most common cause is using NFS to access the repository (subtle interoperability problems between different NFS implementations are unfortunately common). Less common causes are hardware problems or someone manually editing the file. -Larry Jones ...That would be pretty cool, if they weren't out to kill me. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
get cvs log to show nothing if a file isn't on a branch?
I'm using cvs log to aggregate logs of what has gone into a specific build (determined by datespec). I'm only interested in one branch at a time. The log invocation is something like this: cvs -q log -N -r$BRANCH -d $DATE1$DATE2 The problem is that if a file doesn't exist on $BRANCH (like it was added to the trunk sometime after the branch was cut), cvs log returns that file's entire history. I can't actually imagine a scenario where you'd want the entire history for a file just because it doesn't meet your filtering criteria. I'm most willing to accept that it's because rlog is old and was written in the halcyon days of heavy cocaine use amongst UNIX developers. But is there a way to suppress this behavior? Am i going to have to add logic that looks at all the tags associated with the file and ignores cvs log's output if $BRANCH doesn't show up there? Is there an easier way? TIA, tyler ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: get cvs log to show nothing if a file isn't on a branch?
Tyler writes: The problem is that if a file doesn't exist on $BRANCH (like it was added to the trunk sometime after the branch was cut), cvs log returns that file's entire history. You need to update your (server) CVS -- that bug was fixed long ago. -Larry Jones Mom must've put my cape in the wrong drawer. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvs log for tag and branches
Ramanuj Singh wrote: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. Please do not post MIME-encoded messages to this list How to see logs of tags and branches in project cvs log to know who is the owner of branch and tag CVS has no concept of ownership. Nobody owns a branch or a tag. and when the branch or tag was done. CVS does not keep track of when tags or branches are applied. You might be able to track that using the taginfo script. See http://www.cvshome.org/docs/manual/cvs-1.11.14/cvs_18.html#SEC175 for more details. -- 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 [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log for tag and branches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim.Hyslop wrote: and when the branch or tag was done. CVS does not keep track of when tags or branches are applied. You might be able to track that using the taginfo script. See http://www.cvshome.org/docs/manual/cvs-1.11.14/cvs_18.html#SEC175 for more details. That's the only way to track `cvs tag' invocations, but if the tag or branch was created via `cvs rtag', then it might be in your history log. Of course, there are other reasons for preferring tag to rtag. Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQFAdHIXLD1OTBfyMaQRAiVtAJ0SxmuWEgezsTRl5s8hHgxMEa1MxwCg0HAd vVWDg7wO7mXq5z2RMPqB798= =vsr8 -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs log for tag and branches
Title: cvs log for tag and branches How to see logs of tags and branches in project to know who is the owner of branch and tag and when the branch or tag was done. The information transmitted is intended only for the person or entity to whom it is addressed and may contain confidential and / or privileged Material. Any review, re-transmission, dissemination or other use of or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from your computer. Thank you for your understanding co-operation. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvs log and UTC
Derek Robert Price wrote: Mark D. Baushke wrote: a bigger question is if that change should also go into things like $Id$ and other RCS keyword expansion strings... Got me here. I tend to avoid RCS keywords as much as possible. I know that they are useful via the `ident' command, but that is supposed to be human readable, I think. Even if it is intended to be machine readable, I would say standards would be better. What do other people think? I agree - consistent date format is good, and using an ISO standard is even better. I think the RCS keywords should also be expanded. Now, having said that, I also have to point out that I'm not aware of all the other utilities that may depend on the keyword expansion - I'd never have considered the impact on `ident', for example. Seems to me the best way to implement this would be to have a global option which controls the date format, something like: -l Display local time for timestamps -u Display UTC for timestamps Default for the next stable release would be -u, then eventually it could be changed to -l. And, of course, all timestamp displays should go through a single function. Regardless, when we're just talking about rewriting scripts using CVS output to parse _more standard_ dates, I personally don't consider the change drastic or the effects catastrophic. In the long run it would certainly be a good thing. Agreed here, as well. -- 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 [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log and UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim.Hyslop wrote: Seems to me the best way to implement this would be to have a global option which controls the date format, something like: -l Display local time for timestamps -u Display UTC for timestamps Maybe. I think I would prefer stressing the ISOness of the new dates, but it's not a big deal. Maybe something more like: -i Display local ISO8601 dates for timestamps. -o Display timestamps in CVS's legacy formats UTC. Default for the next stable release would be -u, then eventually it could be changed to -l. It would default to -i in feature and -o in stable. -o -i would be deprecated in feature and therefore the next stable _series_ of releases. Next feature _series_ (and therefore the following stable) would have -o and -i options removed entirely. And, of course, all timestamp displays should go through a single function. Of course. Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQFAYwCzLD1OTBfyMaQRAiBUAKCyu/Gz6/hPOqK8+eV5H8sRsWPBCQCgkpYr WPIfXaxwu/7q9rARzmI+Deg= =rQqi -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs log and UTC
Title: Message I have been asked to "fix" this by my boss: cvs log returns the timestamp of the file in Coordinated Univeral Time. All other ways of looking at the timestamp return it in local time. Is there any quick, elegant way to get cvs log to display the date in local time? (I think I know the answer.) Thanks. Liza Blaney Intel Corp, Intel Capital Group, DTO 2200 Mission College Blvd, Santa Clara CA 95052-8121 Mail Stop: RNB-4-97 Phone: 408-765-4495 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log and UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Blaney, Liza wrote: Message I have been asked to fix this by my boss: cvs log returns the timestamp of the file in Coordinated Univeral Time. All other ways of looking at the timestamp return it in local time. Is there any quick, elegant way to get cvs log to display the date in local time? (I think I know the answer.) Thanks. I've considered this problem before but have never had the time to implement the solution. The most correct way I have come up with is to add a tagged text type to the client/server protocol using the MT response type. The client/server protocol is defined in such a way (and clients hopefully written in such a way) that unrecognized MT tags have their associated texty passed through as is. Thus, a new tagged type like datetime could be followed by the time in UTC and old clients would pass through the string as is, duplicating the old log format, and new clients, which knew about the new datetime tag, could convert the time to local time. If you do end up implementing this, please send the patch to [EMAIL PROTECTED] and to me in case the bug-cvs list is on the blink again. I would like to see this change go into CVS and then you wouldn't have to maintain a local fork of CVS for your boss. Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQFAYfEpLD1OTBfyMaQRAvqJAJ9GOA3Zjsz29NTODmzTyakP+2uJugCfQ7t4 hh0N5uFa9mS9CpElX02QbZY= =9xb4 -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log and UTC
Blaney, Liza writes: This is a multi-part message in MIME format. Please do not send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! I have been asked to fix this by my boss: cvs log returns the timestamp of the file in Coordinated Univeral Time. All other ways of looking at the timestamp return it in local time. Is there any quick, elegant way to get cvs log to display the date in local time? (I think I know the answer.) Thanks. No, CVS always displays times in UTC. Because of the complexities of client/server mode, a lot of infrastructure would be required to support local time display and no one has felt compelled to do the work. -Larry Jones It's not denial. I'm just very selective about the reality I accept. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log and UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Robert Price wrote: I've considered this problem before but have never had the time to implement the solution. The most correct way I have come up with is to add a tagged text type to the client/server protocol using the MT response type. The client/server protocol is defined in such a way (and clients hopefully written in such a way) that unrecognized MT tags have their associated texty passed through as is. Thus, a new tagged type like datetime could be followed by the time in UTC and old clients would pass through the string as is, duplicating the old log format, and new clients, which knew about the new datetime tag, could convert the time to local time. By the way, there's more on CVS's client/server protocol in the doc/cvsclient.texinfo file. If you have a full installation of CVS and your GNU info program is installed correctly you should be able to access a friendly version of that document by typing `info cvsclient' at a command prompt. With a working but incorrectly installed GNU info and a current CVS source distribution, something like, `info - --directory=cvs-1.11.4/doc --file=cvsclient.info', should work too. Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQFAYfLRLD1OTBfyMaQRAuofAKCMCexVrIW+STp46mV+tQfCOyTDvgCfWPhu iDPMGcbfBpFShylCKxudx4I= =D71c -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log and UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Larry Jones wrote: I have been asked to fix this by my boss: cvs log returns the timestamp of the file in Coordinated Univeral Time. All other ways of looking at the timestamp return it in local time. Is there any quick, elegant way to get cvs log to display the date in local time? (I think I know the answer.) Thanks. No, CVS always displays times in UTC. Because of the complexities of client/server mode, a lot of infrastructure would be required to support local time display and no one has felt compelled to do the work. I wouldn't call a new MT tag a lot of infrastructure. The implementation should be fairly straightforward and simple, I should think. For you to use the MT command, there is at least one example in the WriteLetter() function in update.c, but you should be able to find others by grepping the source for MT. The handle_mt() function in client.c would be the place where the new datetime tag and its text would need to be converted into a local time. Other than that the only necessary change should be to avoid printing the whole line containing the time in src/log.c, or maybe src/rcs.c, and break the line up into a series of MT commands. Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQFAYfXxLD1OTBfyMaQRAoZwAJ9fa1XhMa4bWR3TJ9BHuC7j/uAShACgxUnO cx1BcJCMn/gmCJNqoNOGe4M= =c2qe -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log and UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Blaney, Liza [EMAIL PROTECTED] writes: I have been asked to fix this by my boss: Summary: It is not a bug and does not need to be fixed. (See also the advice for engineers to a PHB via the Dilbert.com site.) cvs log returns the timestamp of the file in Coordinated Univeral Time. This is correct. All other ways of looking at the timestamp return it in local time. I believe you to be mistaken. Could you please cite examples? I do not believe that cvs will ever OUTPUT time in localtime. If it does, it is probably a bug. Had you said that by default you are able to ENTER a timestamp for checkout (the -D switch) in localtime, then I would have to agree with you. Data entry will also accept '2004/03/22 21:11:06 UTC' as a datestamp and mean UTC instead of localtime. I believe you will find that 'cvs log', 'cvs rlog', 'cvs diff', 'cvs rdiff', 'cvs annotate', 'cvs rannotate' are all using times and dates generated from the UTC representation of the change. Is there any quick, elegant way to get cvs log to display the date in local time? (I think I know the answer.) Thanks. PHB-workaround Sure thing... Have your boss add the following line to his .profile TZ=GMT; export TZ or the following line to his .cshrc setenv TZ GMT and he will find that the output of cvs log will have dates very similar to the 'date' command he issues. Of course, this may not work in a Windows environment, but I am sure you get the idea. Or, you can teach your boss the 'date -u' command. /PHB-workaround In all seriousness, you should ask your boss if he really wants to confuse folks who need to use your cvs repository about what time a change was made by having it appear differently depending on the machine in the network they happened to be logged into at the time. I regularly login to machines in UTC-0800 UTC-0500 and UTC+0530 and it is even more exciting when some of those machines automagically switch to UTC-0700 UTC-0400 during daylight savings time. I expect the output to be the same regardless of the window in which I happen to type a 'cvs log' command. The only way to deal with world-wide development teams is to have a single time standard used for the important stuff and UTC is just the standard to use for cvs. Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAYfZe3x41pRYZE/gRAkBVAJ9mlFjx63qXjwA5wpFqPLlhKLMYHwCgm9tc O9ksG/AOKJjCWjJ3Wj4uWE8= =U4YT -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log and UTC
I use change logs generated by cvs2cl.pl http://www.red-bean.com/cvs2cl and the XSLT transformation from http://www-106.ibm.com/developerworks/library/us-gentoo4, all of which produces very useful HTML, with the advantage that I can set the time zone to whatever I want for different HTML reports. If your boss wants to see local timestamps on cvs output, that's much more work, as others have pointed out. ~Matt signature.asc Description: This is a digitally signed message part ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log and UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark D. Baushke wrote: Blaney, Liza [EMAIL PROTECTED] writes: I have been asked to fix this by my boss: Summary: It is not a bug and does not need to be fixed. (See also the advice for engineers to a PHB via the Dilbert.com site.) This is debatable. cvs log returns the timestamp of the file in Coordinated Univeral Time. This is correct. All other ways of looking at the timestamp return it in local time. I believe you to be mistaken. Could you please cite examples? I do not believe that cvs will ever OUTPUT time in localtime. If it does, it is probably a bug. Had you said that by default you are able to ENTER a timestamp for checkout (the -D switch) in localtime, then I would have to agree with you. Data entry will also accept '2004/03/22 21:11:06 UTC' as a datestamp and mean UTC instead of localtime. This is what I definately consider a bug, or at least a serious usability issue: when the time string output by `cvs log' is copied and pasted into the argument for -D from any other command, it is interpreted as localtime. At the least, `cvs log' output should be changed to contain the UTC string. I believe you will find that 'cvs log', 'cvs rlog', 'cvs diff', 'cvs rdiff', 'cvs annotate', 'cvs rannotate' are all using times and dates generated from the UTC representation of the change. Yep. Is there any quick, elegant way to get cvs log to display the date in local time? (I think I know the answer.) Thanks. PHB-workaround Sure thing... Have your boss add the following line to his .profile TZ=GMT; export TZ or the following line to his .cshrc setenv TZ GMT and he will find that the output of cvs log will have dates very similar to the 'date' command he issues. Of course, this may not work in a Windows environment, but I am sure you get the idea. Or, you can teach your boss the 'date -u' command. /PHB-workaround Mark, I think you just proved a point in favor of changing the log time output to localtime. This is that most commands with output intended to be read by humands will output time dependent on the value of TZ, and CVS should follow this lead when its output is intended primarily to be read by humans. I would argue that annotate fits this category (and rlog, of course), but diff and rdiff, by virtue of their output beign mainly designed to be machine parsable and their format being defined elsewhere, should not honor TZ. The `cvs log' output is definately not designed to be machine parsable, as you would likely know if you have ever tried to parse it. In all seriousness, you should ask your boss if he really wants to confuse folks who need to use your cvs repository about what time a change was made by having it appear differently depending on the machine in the network they happened to be logged into at the time. I regularly login to machines in UTC-0800 UTC-0500 and UTC+0530 and it is even more exciting when some of those machines automagically switch to UTC-0700 UTC-0400 during daylight savings time. I expect the output to be the same regardless of the window in which I happen to type a 'cvs log' command. The only way to deal with world-wide development teams is to have a single time standard used for the important stuff and UTC is just the standard to use for cvs. And you should set your TZ environment variable to GMT or UTC on all these systems after this bug is fixed if that is what you really want to see. Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQFAYftuLD1OTBfyMaQRAjWyAJ4/GZyKrtIrZkCy/MVPmqBENc+8kACgvpf7 Gjhsu59iDFNqVqi/2j0ENLU= =HBb9 -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log and UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthew Doar wrote: If your boss wants to see local timestamps on cvs output, that's much more work, as others have pointed out. I still say there are only two minor edits that would need to be made to the CVS source. Three if you want to include the `annotate' output. Not that I have the time just now, I must admit. Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQFAYf5MLD1OTBfyMaQRAuo6AJ9ubdEuD0tzRMLOaVtPY5TJf/k3NQCg5LDJ D2o2GRP60BN/eDQo1P0Dkyg= =lZ5C -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log and UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Robert Price [EMAIL PROTECTED] writes: Mark D. Baushke wrote: Blaney, Liza [EMAIL PROTECTED] writes: I have been asked to fix this by my boss: Summary: It is not a bug and does not need to be fixed. (See also the advice for engineers to a PHB via the Dilbert.com site.) This is debatable. So it seems. :-) cvs log returns the timestamp of the file in Coordinated Univeral Time. This is correct. All other ways of looking at the timestamp return it in local time. I believe you to be mistaken. Could you please cite examples? I do not believe that cvs will ever OUTPUT time in localtime. If it does, it is probably a bug. Had you said that by default you are able to ENTER a timestamp for checkout (the -D switch) in localtime, then I would have to agree with you. Data entry will also accept '2004/03/22 21:11:06 UTC' as a datestamp and mean UTC instead of localtime. This is what I definately consider a bug, or at least a serious usability issue: when the time string output by `cvs log' is copied and pasted into the argument for -D from any other command, it is interpreted as localtime. At the least, `cvs log' output should be changed to contain the UTC string. I have a minor quibble, the timezone should be numeric - rather than the alphabetic UTC. However, I agree that a timezone indication in the output of cvs log and friends would be reasonable. Is there any quick, elegant way to get cvs log to display the date in local time? (I think I know the answer.) Thanks. PHB-workaround Sure thing... Have your boss add the following line to his .profile TZ=GMT; export TZ or the following line to his .cshrc setenv TZ GMT and he will find that the output of cvs log will have dates very similar to the 'date' command he issues. Of course, this may not work in a Windows environment, but I am sure you get the idea. Or, you can teach your boss the 'date -u' command. /PHB-workaround Mark, I think you just proved a point in favor of changing the log time output to localtime. This is that most commands with output intended to be read by humands will output time dependent on the value of TZ, and CVS should follow this lead when its output is intended primarily to be read by humans. I won't deny it. I would argue that annotate fits this category (and rlog, of course), but diff and rdiff, by virtue of their output beign mainly designed to be machine parsable and their format being defined elsewhere, should not honor TZ. The output of 'cvs diff' at least specifies the timezeone - already. The `cvs log' output is definately not designed to be machine parsable, as you would likely know if you have ever tried to parse it. I have many thounsands of lines of perl, gawk and C spread across multiple companies that parse the 'cvs log' and 'cvs rlog' output and I understand the problem of trying to machine parse such output very clearly. I will also state that if a change to the output of 'cvs log' and 'cvs rlog' to add the timezeone is performed, there is likely going to need to be a compatibility switch for the old format to allow the transition to be chosen by the cvs administrators. In all seriousness, you should ask your boss if he really wants to confuse folks who need to use your cvs repository about what time a change was made by having it appear differently depending on the machine in the network they happened to be logged into at the time. I regularly login to machines in UTC-0800 UTC-0500 and UTC+0530 and it is even more exciting when some of those machines automagically switch to UTC-0700 UTC-0400 during daylight savings time. I expect the output to be the same regardless of the window in which I happen to type a 'cvs log' command. The only way to deal with world-wide development teams is to have a single time standard used for the important stuff and UTC is just the standard to use for cvs. And you should set your TZ environment variable to GMT or UTC on all these systems after this bug is fixed if that is what you really want to see. I've done it before... :-) -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAYf9r3x41pRYZE/gRAn97AKDhnp/x8Q/87zVeZYkZsD1CokwxlACfVIik HV+i7aDtPsFIgeSRuCboO2c= =P0bJ -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log and UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark D. Baushke wrote: Derek Robert Price [EMAIL PROTECTED] writes: I have a minor quibble, the timezone should be numeric - rather than the alphabetic UTC. However, I agree that a timezone indication in the output of cvs log and friends would be reasonable. Um, yes. If I'd thought about the matter more I probably would have suggested the same thing. The `cvs log' output is definately not designed to be machine parsable, as you would likely know if you have ever tried to parse it. I have many thounsands of lines of perl, gawk and C spread across multiple companies that parse the 'cvs log' and 'cvs rlog' output and I understand the problem of trying to machine parse such output very clearly. Excuse me - I should have said, as you _will_ likely know... :) I will also state that if a change to the output of 'cvs log' and 'cvs rlog' to add the timezeone is performed, there is likely going to need to be a compatibility switch for the old format to allow the transition to be chosen by the cvs administrators. Since the server upgrade would not be sufficient to cause the output format to change (in the tagged text case under discussion), and the clients would need to be upgraded, would you consider it sufficient that they admin could specify a path to the old client in their scripts even though they had upgraded their server? Hrm. Probably not. A compatibility switch wouldn't be a big deal though I might vote that the feature code at least issue a deprecation warning when such a switch was used. Then we can remove the date-compatibility option entirely in the next stable release. :) Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQFAYgGKLD1OTBfyMaQRAk06AKDl+yB9jChmrhqs/d0qL3OTyj6I2ACfbptg dzlK0xw8+or+y/D9rdZzQa4= =P3nl -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log and UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Robert Price [EMAIL PROTECTED] writes: Mark D. Baushke wrote: Derek Robert Price [EMAIL PROTECTED] writes: I have a minor quibble, the timezone should be numeric - rather than the alphabetic UTC. However, I agree that a timezone indication in the output of cvs log and friends would be reasonable. Um, yes. If I'd thought about the matter more I probably would have suggested the same thing. In fact, I suggest that movement to ISO 8601 format for output would be desirable. That is, ISO 8601 format -dd-mm hh:mm:ss - vs cvs log's format of '/mm/dd hh:mm:ss' a bigger question is if that change should also go into things like $Id$ and other RCS keyword expansion strings... I will also state that if a change to the output of 'cvs log' and 'cvs rlog' to add the timezeone is performed, there is likely going to need to be a compatibility switch for the old format to allow the transition to be chosen by the cvs administrators. Since the server upgrade would not be sufficient to cause the output format to change (in the tagged text case under discussion), and the clients would need to be upgraded, would you consider it sufficient that they admin could specify a path to the old client in their scripts even though they had upgraded their server? Hrm. Probably not. A compatibility switch wouldn't be a big deal though I might vote that the feature code at least issue a deprecation warning when such a switch was used. Then we can remove the date-compatibility option entirely in the next stable release. :) I suspect this may depend on how extensive the changes are with regard to keyword expansion and what the user community feels should happen. If we are opening the hood on timestamp changes, we probably want to get a good look at all the places that timestamps are used and make sure we understand how it relates to this change. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAYgPP3x41pRYZE/gRAo3OAJ9//bfpNF8WDyLJoEx3xZ1fitzRhgCg40m2 Q6Rpm81R2vw92eOYY/g/MjY= =HZaK -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log and UTC
Mark D. Baushke writes: ISO 8601 format -dd-mm hh:mm:ss - You've got the mm and dd swapped, it's -mm-dd hh:mm:ss -. -Larry Jones The hardest part for us avant-garde post-modern artists is deciding whether or not to embrace commercialism. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvs log and UTC
Yes, please, I can't tell you the hell I've had recently with Timezones being non-numeric. Did you know that Australia has a EST timezone that nicely corresponds to the East coast of the united states? donald -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derek Robert Price Sent: Wednesday, March 24, 2004 4:46 PM To: Mark D. Baushke Cc: Liza Blaney; [EMAIL PROTECTED] Subject: Re: cvs log and UTC -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark D. Baushke wrote: Derek Robert Price [EMAIL PROTECTED] writes: I have a minor quibble, the timezone should be numeric - rather than the alphabetic UTC. However, I agree that a timezone indication in the output of cvs log and friends would be reasonable. Um, yes. If I'd thought about the matter more I probably would have suggested the same thing. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log and UTC
--- Forwarded mail from [EMAIL PROTECTED] Derek Robert Price [EMAIL PROTECTED] writes: Mark D. Baushke wrote: The `cvs log' output is definately not designed to be machine parsable, as you would likely know if you have ever tried to parse it. I have many thounsands of lines of perl, gawk and C spread across multiple companies that parse the 'cvs log' and 'cvs rlog' output and I understand the problem of trying to machine parse such output very clearly. There should be little need to parse the output of cvs log or cvs rlog if you have access to the server and can run rinfo on the RCS files. It produces output that's designed to be machine readable. Sources are located at: http://www.wakawaka.com/source.html --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log and UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Sander [EMAIL PROTECTED] writes: There should be little need to parse the output of cvs log or cvs rlog if you have access to the server and can run rinfo on the RCS files. It produces output that's designed to be machine readable. Sources are located at: http://www.wakawaka.com/source.html Thank you for the pointer. I have been aware of rinfo for a number of years, but it is a good thing to remind folks it exists. That said, access to the server for such purposes is not always available. It depends on the nature of the organizations/companies that maintain the cvs repository and how strictly the repository sources are kept as to wether having access to the raw ,v files will be possible for the rinfo command to use. There are also some CVS concepts with regard to 'magic branches' and the dead state that are not really accounted for by the rinfo program (or such is my recollection from a few years ago). If someone were to provide similar functionality into a patch to provide something like a 'cvs info' or 'cvs rinfo' command, I suspect that many folks would find it useful. Thanks, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAYhr53x41pRYZE/gRAk7OAJ9Y6DCN83fCQ9bHI6FW2dOHjDKmUwCcCfFO EkDPG+N8MVoApzt8DVPthxc= =/5wx -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log and UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Larry Jones [EMAIL PROTECTED] writes: Mark D. Baushke writes: ISO 8601 format -dd-mm hh:mm:ss - You've got the mm and dd swapped, it's -mm-dd hh:mm:ss -. Yes. Mea culpa. I cut-n-pasted a line from src/sanity.sh which happens to have been wrong. I have committed the fix to src/sanity.sh for this. Thanks, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAYhZI3x41pRYZE/gRAoFyAJ9XBaJMKPJzjp89ox1ICzLANAF31ACgm2Op 1mW0yfLNMXLlzjFvPVv6GG8= =1I53 -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log and UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark D. Baushke wrote: In fact, I suggest that movement to ISO 8601 format for output would be desirable. That is, ISO 8601 format -mm-dd hh:mm:ss - vs cvs log's format of '/mm/dd hh:mm:ss' [I corrected the ISO 8691 format in the above quote.] It's only a matter of replacing the slashes (`/') with dashes (`-'), so that change should be pretty straightforward too. a bigger question is if that change should also go into things like $Id$ and other RCS keyword expansion strings... Got me here. I tend to avoid RCS keywords as much as possible. I know that they are useful via the `ident' command, but that is supposed to be human readable, I think. Even if it is intended to be machine readable, I would say standards would be better. What do other people think? I suspect this may depend on how extensive the changes are with regard to keyword expansion and what the user community feels should happen. Granted, but the compatibility flag could be attached to lots of commands. Hrm. I think that when I wrote stable/feature up somewhere, I proposed that deprecated features be deprecated for an entire stable release regardless. I don't recall where. My memory just got it confused this pass. Regardless, when we're just talking about rewriting scripts using CVS output to parse _more standard_ dates, I personally don't consider the change drastic or the effects catastrophic. In the long run it would certainly be a good thing. If we are opening the hood on timestamp changes, we probably want to get a good look at all the places that timestamps are used and make sure we understand how it relates to this change. By all means, look. :) What I've heard so far sounds pretty good. Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQFAYi/fLD1OTBfyMaQRAp69AJ9411wHhWISYsv2nRt9RZzV27yetACgzOff q+Hm5GY9N/j45CQVxQUgclw= =DjWd -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: detect commit on any file of a specific module with 'cvs history' or 'cvs log'?
thanks a lot. Will try that. Benno [EMAIL PROTECTED] (Pierre Asselin) wrote in message news:[EMAIL PROTECTED]... benno.loeffler [EMAIL PROTECTED] wrote: I would like to start a contiuous-build whenever something was committed to a particular module in our cvs repository (which is hosted by a service provider). Have a look at the loginfo file, http://www.cvshome.org/docs/manual/cvs-1.11.13/cvs_18.html#SEC171 . The examples there send email and update a reference sandbox after each commit, but you could make it trigger your build as well. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs log command help
All; I am trying to find out the file name and revision number of every file that is tagged by a release tag. My first thought is to use the log command and parse the output. So I type: cvs log -rTAG_NAME -sRel MY_Directory enter . My reasons for the options are: -rTAG_NAME - I only want the revisions with this tag. -sRel - I only want files that are in the Rel state. What I get back is a listing of all the files tagged with this label + a whole bunch of stuff in the Attic that is not tagged. Why does log read the files in the Attic if they are not tagged. Am I missing the meaning of the options? Am I missing an option? Please let me know how you generate a file listing to go into a version description document.? I even went so far as to checkout the module using the -rTAG_NAME option but that didn't help. Thank you Joseph ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log command help
[EMAIL PROTECTED] writes [in one very long line]: I am trying to find out the file name and revision number of every file that is tagged by a release tag. My first thought is to use the log command and parse the output. So I type: cvs log -rTAG_NAME -sRel MY_Directory enter . See: http://www.cvshome.org/docs/manual/cvs-1.11.7/cvs_16.html#SEC143 Pay particular attention to the -S option (although you may find some of the other options to be of use, too). -Larry Jones I wonder if you can refuse to inherit the world. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log problem
Sorry to spam everyone. After a detailed investigation I found the log message works correctly using cvs 1.11.5, but I also found that I cannot use log to identify all changes between two tags. I am trying to identify All changes by using -- cvs log -rus-1-0-9-78::us-1-0-9-80 -- I have determined that cvs lists all modifications between the two tags, but will not list additions or deletions. It appears that a file must have both tags or it is ignored. I guess that it makes sense -- it is hard to list what is between if you only have one end. Does anyone know how to identify ALL changes between two tags? Larry Lords I just upgraded by windows system from CVSNT 2.0.4(?) to cvs 1.11.5 and the log appears to be working correctly now. I will do some more detail checking, but it looks good. Larry Lords +++ I am seeing some of the same problems. There are times it seems to work, and other times I just get the root directory files. Is there a way of getting the latest version for a window's cvs client without downloading the source and building it from scratch? I believe it is my CVSNT client that could be some of the problem. Thanks for your help, Larry Lords [EMAIL PROTECTED] 09/10/03 12:14PM Ralph Jocham writes: When I add the -S option I only get the files I modified listed, which is good. However, I also only get those in the root directory of the module (i.e. not in the subdirectories), which is bad. There is nothing in the -S option that prevents recursion -- if you're not seeing any files in subdirectories, it's because there aren't any selected revisions in any of them. Run the command without the -S and see what selected revisions: is for those files. If it's not zero and you still don't see those files when you add -S, try upgrading to the latest release of CVS (1.11.6) on both the client and the server. If that still doesn't help, let us know. -Larry Jones What's the matter? Don't you trust your own kid?! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs -- This message may contain confidential information, and is intended only for the use of the individual(s) to whom it is addressed. == ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvs log problem
From: Larry Lords [mailto:[EMAIL PROTECTED] Sent: Thursday, September 11, 2003 9:04 AM To: [EMAIL PROTECTED] Subject: Re: cvs log problem Does anyone know how to identify ALL changes between two tags? Larry Lords cvs rdiff -s -rtag1 -rtag2 module This will give results such as the following: File alpha/OTS/fcs/CHFSFR.OTS changed from revision 1.6 to 1.9 File alpha/OTS/fcs/METTE4.OTS is removed; not included in release tag ver_20030318 File alpha/OTS/static/TMP315.DAT is new; current revision 1.1 Dale Miller ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs log problem
Sorry to trouble you with this question, but I hope some of you gurus already know the answer. When I use the following command I get every file listed in the module regardless of whether or not I changed them, which is bad, cvs log -b -d 2003-03-18 02:40 -wrjocham jboss-3.0.6_tomcat-4.1.18 When I add the -S option I only get the files I modified listed, which is good. However, I also only get those in the root directory of the module (i.e. not in the subdirectories), which is bad. cvs log -b -d 2003-03-18 02:40 -S -wrjocham jboss-3.0.6_tomcat-4.1.18 Any ideas how I can list just the files I changed after a certain date for all the subdirectories (recursive) of the module? Thanks, Ralph __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log problem
Ralph Jocham writes: When I add the -S option I only get the files I modified listed, which is good. However, I also only get those in the root directory of the module (i.e. not in the subdirectories), which is bad. There is nothing in the -S option that prevents recursion -- if you're not seeing any files in subdirectories, it's because there aren't any selected revisions in any of them. Run the command without the -S and see what selected revisions: is for those files. If it's not zero and you still don't see those files when you add -S, try upgrading to the latest release of CVS (1.11.6) on both the client and the server. If that still doesn't help, let us know. -Larry Jones What's the matter? Don't you trust your own kid?! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log problem
I am seeing some of the same problems. There are times it seems to work, and other times I just get the root directory files. Is there a way of getting the latest version for a window's cvs client without downloading the source and building it from scratch? I believe it is my CVSNT client that could be some of the problem. Thanks for your help, Larry Lords [EMAIL PROTECTED] 09/10/03 12:14PM Ralph Jocham writes: When I add the -S option I only get the files I modified listed, which is good. However, I also only get those in the root directory of the module (i.e. not in the subdirectories), which is bad. There is nothing in the -S option that prevents recursion -- if you're not seeing any files in subdirectories, it's because there aren't any selected revisions in any of them. Run the command without the -S and see what selected revisions: is for those files. If it's not zero and you still don't see those files when you add -S, try upgrading to the latest release of CVS (1.11.6) on both the client and the server. If that still doesn't help, let us know. -Larry Jones What's the matter? Don't you trust your own kid?! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs -- This message may contain confidential information, and is intended only for the use of the individual(s) to whom it is addressed. == ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log problem
I just upgraded by windows system from CVSNT 2.0.4(?) to cvs 1.11.5 and the log appears to be working correctly now. I will do some more detail checking, but it looks good. Larry Lords +++ I am seeing some of the same problems. There are times it seems to work, and other times I just get the root directory files. Is there a way of getting the latest version for a window's cvs client without downloading the source and building it from scratch? I believe it is my CVSNT client that could be some of the problem. Thanks for your help, Larry Lords [EMAIL PROTECTED] 09/10/03 12:14PM Ralph Jocham writes: When I add the -S option I only get the files I modified listed, which is good. However, I also only get those in the root directory of the module (i.e. not in the subdirectories), which is bad. There is nothing in the -S option that prevents recursion -- if you're not seeing any files in subdirectories, it's because there aren't any selected revisions in any of them. Run the command without the -S and see what selected revisions: is for those files. If it's not zero and you still don't see those files when you add -S, try upgrading to the latest release of CVS (1.11.6) on both the client and the server. If that still doesn't help, let us know. -Larry Jones What's the matter? Don't you trust your own kid?! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs -- This message may contain confidential information, and is intended only for the use of the individual(s) to whom it is addressed. == ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log problem
Larry Lords writes: Is there a way of getting the latest version for a window's cvs client without downloading the source and building it from scratch? I believe it is my CVSNT client that could be some of the problem. There are binaries on cvshome.org, but it appears that Derek hasn't published one for the latest version yet, 1.11.5 is the most recent. http://ftp.cvshome.org/release/binary/win32/ -Larry Jones Nothing spoils fun like finding out it builds character. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Lock contention executing cvs log
MacDonald, Ian writes: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary91921517666352637== Please do not send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! Shouldn't cvs simply be using read locks while executing the log command? It should, and it is. If that's the case, why is there a contention for the read locks? Because you need an exclusive lock to create a read lock. The exclusive lock is only held for a very short time (just long enough to create the read lock), but it's still possible for there to be contention for it. -Larry Jones I must have been delirious from having so much fun. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Lock contention executing cvs log
Title: RE: Lock contention executing cvs log Thanks Larry, Sorry for the MIME post. I realized that I forgot to turn it off after sending it (and you can't un-send a message). Not sure if you saw my follow up. But I'm now thinking that the lock contention is not the source of my performance problems, just a side effect. My theory is that the CVS processes are effectively serializing themselves by virtue of using up most of the available memory while they operate on a particular directory. When a large cvs process releases enough memory for another cvs process to operate freely, the new process runs into several of other cvs processes which were also now trying to do the same thing which is acquire a read lock on the next directory. Another clue is that I can start several build cycles on different hosts at random start times (15-20 minutes apart), but they eventually become synchronized and all finish within a few seconds of each other. I guess my question now is why the cvs processed grow so large. Can you characterize how cvs should behave with respect to memory allocations when performing a log command over a set of directories? Regards, -- Ian MacDonald -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, February 28, 2003 8:13 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Lock contention executing cvs log MacDonald, Ian writes: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary91921517666352637== Please do not send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! Shouldn't cvs simply be using read locks while executing the log command? It should, and it is. If that's the case, why is there a contention for the read locks? Because you need an exclusive lock to create a read lock. The exclusive lock is only held for a very short time (just long enough to create the read lock), but it's still possible for there to be contention for it. -Larry Jones I must have been delirious from having so much fun. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Lock contention executing cvs log
Title: RE: Lock contention executing cvs log (Hopefully this time at plain-text) - Sorry again Thanks Larry, Sorry for the MIME post. I realized that I forgot to turn it off after sending it (and you can't un-send a message). Not sure if you saw my follow up. But I'm now thinking that the lock contention is not the source of my performance problems, just a side effect. My theory is that the CVS processes are effectively serializing themselves by virtue of using up most of the available memory while they operate on a particular directory. When a large cvs process releases enough memory for another cvs process to operate freely, the new process runs into several of other cvs processes which were also now trying to do the same thing which is acquire a read lock on the next directory. Another clue is that I can start several build cycles on different hosts at random start times (15-20 minutes apart), but they eventually become synchronized and all finish within a few seconds of each other. I guess my question now is why the cvs processed grow so large. Can you characterize how cvs should behave with respect to memory allocations when performing a log command over a set of directories? Regards, -- Ian MacDonald -Original Message- From: MacDonald, Ian [mailto:[EMAIL PROTECTED]] Sent: Friday, February 28, 2003 11:02 AM To: [EMAIL PROTECTED] Subject: RE: Lock contention executing cvs log Thanks Larry, Sorry for the MIME post. I realized that I forgot to turn it off after sending it (and you can't un-send a message). Not sure if you saw my follow up. But I'm now thinking that the lock contention is not the source of my performance problems, just a side effect. My theory is that the CVS processes are effectively serializing themselves by virtue of using up most of the available memory while they operate on a particular directory. When a large cvs process releases enough memory for another cvs process to operate freely, the new process runs into several of other cvs processes which were also now trying to do the same thing which is acquire a read lock on the next directory. Another clue is that I can start several build cycles on different hosts at random start times (15-20 minutes apart), but they eventually become synchronized and all finish within a few seconds of each other. I guess my question now is why the cvs processed grow so large. Can you characterize how cvs should behave with respect to memory allocations when performing a log command over a set of directories? Regards, -- Ian MacDonald -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, February 28, 2003 8:13 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Lock contention executing cvs log MacDonald, Ian writes: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary91921517666352637== Please do not send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! Shouldn't cvs simply be using read locks while executing the log command? It should, and it is. If that's the case, why is there a contention for the read locks? Because you need an exclusive lock to create a read lock. The exclusive lock is only held for a very short time (just long enough to create the read lock), but it's still possible for there to be contention for it. -Larry Jones I must have been delirious from having so much fun. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Lock contention executing cvs log
MacDonald, Ian writes: While several of my build processes were running, I was monitoring the CVS server with 'top'. I noticed a strange occurrence with two of cvs processes that were currently executing a log command - both processes grew to consume nearly all available memory (in my case 512MB). While this was occurring, the cvs clients associated with these growing cvs processes started dumping the 'waiting for blahs lock' messages to stdout. This went on for about 15 minutes before the log commands completed. Does anyone know if this is normal behavior? Probably. CVS can be quite memory intensive. Now, that's generally *virtual* memory, so it doesn't matter so much. If you were running a version of top that's similar to the one I have, SIZE is the amount of virtual memory a process is using, RES is the amount of real memory. You had to have been looking at SIZE rather than RES since it isn't possible for two processes to both be using nearly all the physical memory. Don't forget that virtual memory is paged rather than processes being swapped, so the two processes don't interfere with each other -- it's not necessary for one to wait for the other to release some virtual memory before it can procede. In fact, I suspect you'll find that the processes *never* release virtual memory; they start out growing, they may or may not eventually stabilize; if they do, they stay that size until they end; they never shrink. I think what you're seeing is, indeed, lock contention. Whichever process starts first has to actually read the data off the disk and is constantly stopping and waiting for that to happen. The second process, however, finds all the data it needs in the filesystem cache (courtesy of the first process) and thus can proceed much faster until it finally catches up. Once that happens, the two process procede more-or-less in lockstep and end up running into each other the next time they try to create read locks. Waiting for a lock is a very time consuming process -- the current code just sleeps for 30 seconds and then tries again. I just checked in a change that modifies the algorithm slightly. When contention is encountered, the code now makes a few retry attempts with a very short time wait time (initially 2 us with an exponential backoff) before giving up and going into the fullblown wait with messages and the 30 second wait. That should significantly reduce the impact of contention. In my test with two simultaneous log processes, there was lots of contention, but the second process usually got through after a single retry and never needed more than 3 (I allow up to 9 retries which is a total delay of about 1ms). Of course, if there's enough contention, you'll still end up in the old 30 second wait with a message code. Better would be to make the whole waiting process use a random wait with exponential backoff; that should help avoid process that have gotten in lockstep all trying to grab the master lock at the same time. -Larry Jones I've never seen a sled catch fire before. -- Hobbes ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Lock contention executing cvs log
Title: Lock contention executing cvs log Hi Folks, I'm sorry if this posting might appear twice. I first posted this to the NNTP group gnu.cvs.help but was not sure my posts were actually making it. Here's my problem: We have an automated build environment (CruiseControl) running on multiple hosts that poll for changes in a cvs repository using the cvs log command. We are seeing a problem that seems to be resulting in an inordinate amount of time executing the log command. When to two or more of the hosts are executing cvs -q log -N -d upperdate Lowerdate -b on the same module they seem to get stuck in a lockstep mode of waiting for each others locks with each module taking upwards of a minute. For our respository this adds up to 30 minutes to each build cycle scanning for changes. Shouldn't cvs simply be using read locks while executing the log command? If that's the case, why is there a contention for the read locks? Perhaps there is a write lock getting created? Any assistance would be appreciated. Thanks, -- Ian MacDonald ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Lock contention executing cvs log
This is a follow up with some more observations: While several of my build processes were running, I was monitoring the CVS server with 'top'. I noticed a strange occurrence with two of cvs processes that were currently executing a log command - both processes grew to consume nearly all available memory (in my case 512MB). While this was occurring, the cvs clients associated with these growing cvs processes started dumping the 'waiting for blahs lock' messages to stdout. This went on for about 15 minutes before the log commands completed. Does anyone know if this is normal behavior? BTW, in case you're curious, the log command is running against a source tree with ~1.5 GB of mixed binary and text source files. I think the biggest binary file is ~30MB. Regards, -- Ian MacDonald -Original Message- From: MacDonald, Ian [mailto:[EMAIL PROTECTED] Sent: Thursday, February 27, 2003 12:10 PM To: '[EMAIL PROTECTED]' Subject: Lock contention executing cvs log Hi Folks, I'm sorry if this posting might appear twice. I first posted this to the NNTP group gnu.cvs.help but was not sure my posts were actually making it. Here's my problem: We have an automated build environment (CruiseControl) running on multiple hosts that poll for changes in a cvs repository using the cvs log command. We are seeing a problem that seems to be resulting in an inordinate amount of time executing the log command. When to two or more of the hosts are executing cvs -q log -N -d upperdate Lowerdate -b on the same module they seem to get stuck in a lockstep mode of waiting for each others locks with each module taking upwards of a minute. For our respository this adds up to 30 minutes to each build cycle scanning for changes. Shouldn't cvs simply be using read locks while executing the log command? If that's the case, why is there a contention for the read locks? Perhaps there is a write lock getting created? Any assistance would be appreciated. Thanks, -- Ian MacDonald ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvs log (newbie)
Hiya When using cvs log filename does anyone know where this function is called from and when the actual log information is retrieved from. I know it has something to do with loginfo file in cvsroot/CVSROOT but cant see where it retrieves the log info from exactly. Thanx (this info) RCS file: C:\cvsproject/phpproject/login.php,v Working file: login.php head: 1.2 branch: locks: strict access list: symbolic names: arelease: 1.1.1.1 avendor: 1.1.1 keyword substitution: kv total revisions: 3; selected revisions: 3 description: revision 1.2 date: 2003/02/05 19:18:26; author: bobby_rahman; state: Exp; lines: +1 -1 This is a test to see CVS works revision 1.1 date: 2003/02/05 19:15:46; author: bobby_rahman; state: Exp; branches: 1.1.1; Initial revision revision 1.1.1.1 date: 2003/02/05 19:15:46; author: bobby_rahman; state: Exp; lines: +0 -0 no message = *CVS exited normally with code 0* _ Worried what your kids see online? Protect them better with MSN 8 http://join.msn.com/?page=features/parentalpgmarket=en-gbXAPID=186DI=1059 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log (newbie)
Hiya When using cvs log filename does anyone know where this function is called from and when the actual log information is retrieved from. The function exists within CVS, and it retrieves the log information from the file in the repository. I know it has something to do with loginfo file in cvsroot/CVSROOT but cant see where it retrieves the log info from exactly. It has nothing to do with loginfo. The loginfo file is there to provide processing after commit. Thanx (this info) RCS file: C:\cvsproject/phpproject/login.php,v OK, so now log into the server (if it isn't local), fire up your favorite editor, and look at that file above. You will find the cvs log info directly in the file. CVS just copies it out, as far as I can tell offhand, without changing it in any way (except to delete parts of it as requested by the options). Working file: login.php head: 1.2 branch: locks: strict access list: symbolic names: arelease: 1.1.1.1 avendor: 1.1.1 There is one oddity to notice here: if you have a branch (like release_1), it will show up as something like 1.1.0.2 rather than the more intuitive 1.1.2. -- Now building a CVS reference site at http://www.thornleyware.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Ignore no revision warning in cvs log
Is there a way to ignore the no revision warning message when using the cvs log command? I am using a CVS build that I checked out from around 11/11/02 timeframe to use the new cvs log -r tag1::tag2 syntax. But if tag1 does not exist in the file (e.g., a new file that was added), CVS currently gives a warning but doesn't print any log information. I would think you still want to see the log for tag2. Otherwise there is no way to know a file was added. Thanks, -- Patrick Lee [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Problem with CR in cvs log.
Larry Jones wrote: Apostolos Manolitzas writes: I use cvs 1.11.1p1 in my Linux box (RH7.1). The linux box is the client and the server uses cvsnt (win2000) on a windows machine. CVSNT is entirely separate from CVS -- you should probably ask this question on the CVSNT mailing list (see http://www.cvsnt.com/). cvs server: Logging . cvs [server aborted]: linefeed expected in C:/cvsrepo/test/file.c,v (got 13) I think that the problem is obvious and I have read several mails describing the same problem: The windows use CRLF instead of the LF that the cvs log requires. That should be irrelevant -- files in the repository are *binary* files, so the standard line ending conventions don't apply to them. As far as I understand from the info pages of cvs (Where files are stored within the repository ) the files are stored in RCS format which doesn't mean that are in binary form. Also you can check from the man page to that even for the binary files thereis a specific option in order to avoid the transformation (info cvs : Handling binary files ). Either something is horribly wrong with CVSNT (which I sincerely doubt) or someone did something to your repository files with DOS/Windows commands that treated them as text files and thus corrupted them. -Larry Jones Like I'm going to get any sleep NOW. -- Calvin -Apostolos ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Problem with CR in cvs log.
Apostolos Manolitzas writes: As far as I understand from the info pages of cvs (Where files are stored within the repository ) the files are stored in RCS format which doesn't mean that are in binary form. Yes, it does. RCS files are *NOT* plain text files -- they may contain arbitrary data and thus must be treated as binary files. Also you can check from the man page to that even for the binary files thereis a specific option in order to avoid the transformation (info cvs : Handling binary files ). That just affects how CVS reads and writes the user files, not how it reads and write RCS files. -Larry Jones Please tell me I'm adopted. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Problem with CR in cvs log.
Hello everybody, I use cvs 1.11.1p1 in my Linux box (RH7.1). The linux box is the client and the server uses cvsnt (win2000) on a windows machine. I am having a problem with the logging. When I try to do cvs log file the server responds with: cvs server: Logging . cvs [server aborted]: linefeed expected in C:/cvsrepo/test/file.c,v (got 13) I think that the problem is obvious and I have read several mails describing the same problem: The windows use CRLF instead of the LF that the cvs log requires. So my question is what it the correct solution of this problem? For testing purposes, I took a backup of the repository (all *,v files) in my linux box and I applied the dos2unix command. After that the repository was working fine locally. But my question is about the windows machine (where the repository is). What should I do to correct the problem? Thank you, Apostolos ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Problem with CR in cvs log.
Apostolos Manolitzas writes: I use cvs 1.11.1p1 in my Linux box (RH7.1). The linux box is the client and the server uses cvsnt (win2000) on a windows machine. CVSNT is entirely separate from CVS -- you should probably ask this question on the CVSNT mailing list (see http://www.cvsnt.com/). cvs server: Logging . cvs [server aborted]: linefeed expected in C:/cvsrepo/test/file.c,v (got 13) I think that the problem is obvious and I have read several mails describing the same problem: The windows use CRLF instead of the LF that the cvs log requires. That should be irrelevant -- files in the repository are *binary* files, so the standard line ending conventions don't apply to them. Either something is horribly wrong with CVSNT (which I sincerely doubt) or someone did something to your repository files with DOS/Windows commands that treated them as text files and thus corrupted them. -Larry Jones Like I'm going to get any sleep NOW. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs log checking per branch ?
Hi there I am wondering whether there is a way to require a certain cvs log format --per branch--, not per module. For example, I want to require a format like "bugnr: digits" in my release branch, but not in the main branch. The documentation about the "verifymsg" trigger seems to only allow this kind of restriction per module.I suppose that if I had the branch name available in the verifymsg trigger it would be easy to do. Is there a way to get at this info ? Like in the commitinfo trigger, where you have a list of the files to be committed, and so can ask of each file (with "cvs status") which branch it is in? Thanks in advance ! Heikki Heikki DoelemanInfo.nl - Sint Antoniesbreestraat 16 - 1011 HB Amsterdam Tel. +31 (0)20 530 9100- Fax. +31 (0)20 530 9101 [EMAIL PROTECTED] - http://info.nl
Re: CVS: log lines
Myke Olson writes: Is there a way to force the log to begin with a blank line? I liked it better the old way. :) Set up rcsinfo to point to a template file with a blank line in it. -Larry Jones The authorities are trying to silence any view contrary to their own! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to get Log messages between two tags usind cvs log command?
Use cvs rdiff -s to get a summary of the changes between the two tags, and then parse its output and use rlog to retrieve the log messages for the indicated revisions of the indicated files. Check out URL:http://www.mit.edu/~jik/cvsrdiffsum, which will do this for you automatically and produce a summary of the changes, although it won't be in ChangeLog format. If you want to enhance this script to make it support generating output that cvs2cl.pl can parse, or even to do what cvs2cl.pl does directly, I'd gladly accept your enhancements to the script. I'm not sure if cvs2cl.pl handles deleted files properly, i.e., includes in the ChangeLog an indication of the change in which they were deleted. My cvsrdiffsum script doesn't handle this case; it just lists deleted files, without listing when they were deleted. This could probably be fixed, but I haven't felt it necessary. Again, if you want to fix it and send me a patch, that would be great. Note that I applied earlier today to the maintainer of cvshome.org to create a cvsrdiffsum project so that I can publish the script on the CVS Web site, but this hasn't been approved yet, hence the URL above on my personal Web site. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
How to get Log messages between two tags usind cvs log command?
Title: How to get Log messages between two tags usind cvs log command? Hi, There is an option of getting log message between two dates (-d) , between two revisions (-r). Does anybody know how to get log messages between two tags on the same branch. I want to prepare a changelog file using cvs2cl.pl utility. I want to find out what has been changed between two builds (tags) in a given branch. If I use date then cvs gives me changes from all of the branches. I can not use revision because not every file has same revision number. Thanks, -Shailesh Garg Clickmarks Inc.
Re: How to get Log messages between two tags usind cvs log command?
Shailesh Garg writes: This is a multi-part message in MIME format. Please do not send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE. There is an option of getting log message between two dates (-d) , between two revisions (-r). Does anybody know how to get log messages between two tags on the same branch. A tag is a way of specifying a revision, so use -r with your tags. -Larry Jones Geez, I gotta have a REASON for everything? -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvs log question
Use cvs rlog -Original Message- From: Neil Zanella [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 21, 2002 7:52 PM To: [EMAIL PROTECTED] Subject: cvs log question Hello, Is there a way to look at a log file without first checking out? Thanks, Neil ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log question
Neil Zanella writes: Is there a way to look at a log file without first checking out? CVS 1.11.1 and newer have an rlog subcommand to do that. -Larry Jones These findings suggest a logical course of action. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs log question
Hello, Is there a way to look at a log file without first checking out? Thanks, Neil ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS log filter
This has probably been done a thousand times before, but I wrote a simple CVS log parser to get more 'user friendly' output. Especially, output is filtered when number of selected revisions is 0 (I think someone requested this a while ago). source code (MSVC6, gcc 2.95.2) and Win32 executable can be downloaded from www.helsinki.fi/~kajala/code/cvslogfilter.zip cvslogfilter description can be found from www.helsinki.fi/~kajala/code.html Regards, Jani Kajala ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
'cvs log' doesn't show any tags, yet they exist!
This is a weird one, and I coulda sworn this worked for me last week. I can no longer run 'cvs log file.c' in my local repository and see a list of the tags that file.c exists within. I was under the impression that 'cvs log' would display tags. What am I doing wrong here? As an aside, when I use ViewCVS on the same repository, all the tags are intact, and file.c exists in dozens of tags. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: 'cvs log' doesn't show any tags, yet they exist!
David A. Desrosiers writes: This is a weird one, and I coulda sworn this worked for me last week. I can no longer run 'cvs log file.c' in my local repository and see a list of the tags that file.c exists within. I was under the impression that 'cvs log' would display tags. What am I doing wrong here? Are you sure you're not just overlooking the list? The log output labels it symbolic names rather than tags. If not, then you must be using the -N option to suppress the list, perhaps in your ~/.cvsrc file? -Larry Jones All girls should be shipped to Pluto--that's what I say. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: 'cvs log' doesn't show any tags, yet they exist!
Maybe you want cvs_status -v filename Jeanie ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
how do I know that a branch has been merged into trunk from cvs log
I have a module with lots of old branches and lots of revisions. Is there anyway for me to follow the branches and figure out which ones were merged into the truck, and which ones were not? Through cvs log? to give a real world example, as a qa person, I am responsible for assigning release tags to modules. There are developers working on different branches all the time. To tag the trunk, I want to *make* sure that the branch was merged before I do the tagging. I could of course, check the files and see the changes, but I just want to check the entire module with one command line. you could say that I should always tag the trunk after merging back the branch, but that brings possibility of human error. What if there are several qa people who can merge branches back onto trunks?? cheers! mizpoon _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: request for log option to specifically exclude the first tag, workaround for cvs log -r -r
Matthew Herrmann writes: since it would be used pretty commonly -- shame -rTAG1::TAG2 doesn't do what people would expect it to do. Would anyone object to changing it so that it does revisions after TAG1 and not after TAG2 rather than after TAG1 and before TAG2 (e.g., currently it is exclusive of both TAG1 and TAG2, the change would be to make it inclusive for just TAG2)? -Larry Jones I always send Grandma a thank-you note right away. ...Ever since she sent me that empty box with the sarcastic note saying she was just checking to see if the Postal Service was still working. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: request for log option to specifically exclude the first tag, workaround for cvs log -r -r
[ On Tuesday, January 8, 2002 at 13:00:19 (-0500), Larry Jones wrote: ] Subject: Re: request for log option to specifically exclude the first tag, workaround for cvs log -r -r Matthew Herrmann writes: since it would be used pretty commonly -- shame -rTAG1::TAG2 doesn't do what people would expect it to do. Would anyone object to changing it so that it does revisions after TAG1 and not after TAG2 rather than after TAG1 and before TAG2 (e.g., currently it is exclusive of both TAG1 and TAG2, the change would be to make it inclusive for just TAG2)? That sounds much more logical. The goal is to produce a change log for a release. The changes to be described are only those those after TAG1, up to, and including, any for TAG2, iff TAG2 is on a different revision from(after) TAG1. I.e. do not print the log entry for TAG2 if it's on the same revision as TAG1. The analogy is with the cvs diff/patch/rdiff commands where deltas are only displayed if there is a difference to be displayed. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: request for log option to specifically exclude the first tag, workaround for cvs log -r -r
just to clarify, it should include TAG2 only in the case where a tag does not exist for TAG1... -Original Message- From: Larry Jones [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 9 January 2002 05:00 To: Matthew Herrmann Cc: [EMAIL PROTECTED] Subject: Re: request for log option to specifically exclude the first tag, workaround for cvs log -r -r Matthew Herrmann writes: since it would be used pretty commonly -- shame -rTAG1::TAG2 doesn't do what people would expect it to do. Would anyone object to changing it so that it does revisions after TAG1 and not after TAG2 rather than after TAG1 and before TAG2 (e.g., currently it is exclusive of both TAG1 and TAG2, the change would be to make it inclusive for just TAG2)? -Larry Jones I always send Grandma a thank-you note right away. ...Ever since she sent me that empty box with the sarcastic note saying she was just checking to see if the Postal Service was still working. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: request for log option to specifically exclude the first tag, workaround for cvs log -r -r
Matthew Herrmann writes: just to clarify, it should include TAG2 only in the case where a tag does not exist for TAG1... Right. If TAG1 and TAG2 are both attached to the same revision, the revision specified by TAG2 would not be *after* the revision specified by TAG1 and thus would not be included. -Larry Jones Good gravy, whose side are you on?! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
request for log option to specifically exclude the first tag, workaround for cvs log -r -r
Hi all, I think this topic has not been given enough discussion, namely the problem that it is *impossible* through using standard CVS commands to get the log messages _taking_ one from a tag to another tag. This thread got dropped a while ago by people quietly whispering oh well, it can't be done and others saying well it does work, read the newsgroup without trying it. All of the log -rR1::R2 -rR2 etc. style methods all fail in at least some cases, especially when there has been no change to a file over two tags, so a revision number is tagged with both tags (try it!) I think if anything, this is a feature which deserves to be added to the new dev version, as opposed to emacs support or what have you... I was amazed it hasn't been come across before. Anyway, enough rant, I think I may have found a pragmatic workaround that recent discussions about dates inspired me on: find the dates of the two logs, and then do a cvs log from just after the last committed date/time of the first tag, and up to and including the date/time of the last file containing the second tag. But that won't be sufficient if you're using branching -- you'll then need to ensure that you're only getting log messages from the branch containing both tags. I haven't implemented it yet, but ... agh! i think this would be how it works (not tested): run perl/python script to get dates of both tags find maxs/mins and feed these into: cvs log -dDATE1DATE2 -rBRANCH The alternative to allow people to reliably answer the question what does the new version contain? is to include a -r-TAG1 option to _exclude_ any revisions containing TAG1. This means that the following: cvs log -rTAG1::TAG2 -r-TAG1 would actually give the log messages between the two tags (provided -rTAG1::TAG2 includes all changes including the endpoints). actually, i would even like something like: cvs log -rTAG1=TAG2 since it would be used pretty commonly -- shame -rTAG1::TAG2 doesn't do what people would expect it to do. Regards, Matthew Herrmann -- Far Edge Technology Level 11, 80 Mount St North Sydney NSW 2060 Australia Ph: 02 9955 3640 Mob: 0404 852 537 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: request for log option to specifically exclude the first tag, workaround for cvs log -r -r
Have you looked at rinfo? It does what you ask, for a single RCS file. You'd have wrap it in a script that traverses your repository to see all changes in your project. You could also combine it with lmerge to produce more concise reports. Both of these programs are available at http://www.wakawaka.com/source.html --- Forwarded mail from [EMAIL PROTECTED] I think this topic has not been given enough discussion, namely the problem that it is *impossible* through using standard CVS commands to get the log messages _taking_ one from a tag to another tag. This thread got dropped a while ago by people quietly whispering oh well, it can't be done and others saying well it does work, read the newsgroup without trying it. All of the log -rR1::R2 -rR2 etc. style methods all fail in at least some cases, especially when there has been no change to a file over two tags, so a revision number is tagged with both tags (try it!) I think if anything, this is a feature which deserves to be added to the new dev version, as opposed to emacs support or what have you... I was amazed it hasn't been come across before. Anyway, enough rant, I think I may have found a pragmatic workaround that recent discussions about dates inspired me on: find the dates of the two logs, and then do a cvs log from just after the last committed date/time of the first tag, and up to and including the date/time of the last file containing the second tag. But that won't be sufficient if you're using branching -- you'll then need to ensure that you're only getting log messages from the branch containing both tags. I haven't implemented it yet, but ... agh! i think this would be how it works (not tested): run perl/python script to get dates of both tags find maxs/mins and feed these into: cvs log -dDATE1DATE2 -rBRANCH The alternative to allow people to reliably answer the question what does the new version contain? is to include a -r-TAG1 option to _exclude_ any revisions containing TAG1. This means that the following: cvs log -rTAG1::TAG2 -r-TAG1 would actually give the log messages between the two tags (provided -rTAG1::TAG2 includes all changes including the endpoints). actually, i would even like something like: cvs log -rTAG1=TAG2 since it would be used pretty commonly -- shame -rTAG1::TAG2 doesn't do what people would expect it to do. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log messages
I did find out what problem was. Since I was using vim (or gvim) which forked out a separate window, for some reason CVS assumed I had completed typing the log message, even before I actually typed in anything. So now vim does not fork out a separate process. Not sure if this is a bug or not, but I am posting it in the cvs.bug group. Steve Greenland [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... On Wed, Dec 19, 2001 at 12:21:34PM -0500, Jeremiah wrote: I am using CVS on HP-UX 11.00. I use CVS in the bash shell. The CVS version is 1.10.8. When I cvs commit a file, it brings up the vi editor and asks me to put my comments in, which I do. Then it prompts me saying that the log message is empty and if I want to continue or not. Why is not the log message being accepted? Do I need to do somekind of setup? Possibilities: 1. You're not saving the file. Use :wq, not :q!. ;-) 2. Are you using a version of vi (or have you enabled an option) that creates backups by moving the original and then writing a new version? Depending on how the CVS tracks that file, it may not see the new version. Turn that option off. Steve ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs log messages
I am using CVS on HP-UX 11.00. I use CVS in the bash shell. The CVS version is 1.10.8. When I cvs commit a file, it brings up the vi editor and asks me to put my comments in, which I do. Then it prompts me saying that the log message is empty and if I want to continue or not. Why is not the log message being accepted? Do I need to do somekind of setup? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log messages
On Wed, Dec 19, 2001 at 12:21:34PM -0500, Jeremiah wrote: I am using CVS on HP-UX 11.00. I use CVS in the bash shell. The CVS version is 1.10.8. When I cvs commit a file, it brings up the vi editor and asks me to put my comments in, which I do. Then it prompts me saying that the log message is empty and if I want to continue or not. Why is not the log message being accepted? Do I need to do somekind of setup? Possibilities: 1. You're not saving the file. Use :wq, not :q!. ;-) 2. Are you using a version of vi (or have you enabled an option) that creates backups by moving the original and then writing a new version? Depending on how the CVS tracks that file, it may not see the new version. Turn that option off. Steve ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs log and initial revision line counts
Ville Herva wrote: Urmhh, I should have just deleted the sentence as it is clear I was unable to write it unambiguosly. To reiterate, this is what I ment: even you could cook up the patch: you = me, Ville Herva, the author of _this_ and the previous mail seasoned CVS hacker = other people, perhaps including Larry Jones and others (I admit I wasn't 100% sure Larry Jones was one of those, but I kind of addumed that). Again, sorry for the inconvenience, and sorry if I insulted someone. I apologize for the misunderstanding. -Matt ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
