bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

join command, keyword expansion, sticky options: bug and fix


From: Ken . Olstad
Subject: join command, keyword expansion, sticky options: bug and fix
Date: Tue, 19 Mar 2002 11:39:30 -0600

Given a text file foo in CVS with default keyword substitution set in
the repository (i.e. "cvs log -h foo" shows "keyword substitution: kv"),
but with -kk turned on in my sandbox (via "cvs update -kk f1", so
that the working file doesn't have keyword values, and "cvs status foo"
shows sticky option -kk), I was surprised to find that the join command

  cvs update -jA -jB f1

leaves RCS keywords (e.g. $Revision$) with values expanded in the
working file.  That is, somewhere along the way, the merge command
ignores the "-kk" from the CVS/Entries entry.  This is a problem in case
the contents of revision B are the same as the contents of the BASE
revision of file f1 (except for keyword values), because in this case,
f1 becomes Locally Modified, so that a blanket commit will checkin a new
revision of foo, even though there is no change.

Below is a patch, against the tip of the trunk as of this morning, that
fixes this.  I don't feel I know the code or the test suite well enough
to be confident that I didn't break something, but it fixes the problem
and doesn't cause any 'make check' failures.

$ cvs diff
Index: src/update.c
===================================================================
RCS file: /cvs/ccvs/src/update.c,v
retrieving revision 1.197
diff -u -r1.197 update.c
--- src/update.c        8 Jul 2001 20:51:46 -0000       1.197
+++ src/update.c        19 Mar 2002 16:59:30 -0000
@@ -2446,7 +2446,7 @@
        /* The file is up to date.  Need to check out the current 
contents.  */
        retcode = RCS_checkout (vers->srcfile, finfo->file,
                                vers->vn_user, (char *) NULL,
-                               (char *) NULL, RUN_TTY,
+                               vers->options, RUN_TTY,
                                (RCSCHECKOUTPROC) NULL, (void *) NULL);
        if (retcode != 0)
            error (1, 0,



I didn't take the time to figure out how to add a case for this to the
automated test script, but here is a transcript of a session that shows
the pre- and post-fix behavior.  I believe the problem only shows up in
client-server operation.

$ echo $CVSROOT
:fork:/home/keno/test-repository
$ cvs log -h f1 |grep keyword
keyword substitution: kv
$ cvs up -kk f1
U f1
$ cvs st f1
===================================================================
File: f1                Status: Up-to-date

   Working revision:    1.4
   Repository revision: 1.4     /home/keno/test-repository/src/f1,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      -kk

$ cat f1
$Revision$

some lines
of text
who cares?

$ # c1 is an alias for the cvs executable built from the unmodified trunk
$ c1 up -jA -jB f1
RCS file: /home/keno/test-repository/src/f1,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
Merging differences between 1.1.2.2 and 1.1.2.3 into f1
$ cvs st f1
===================================================================
File: f1                Status: Locally Modified

   Working revision:    1.4
   Repository revision: 1.4     /home/keno/test-repository/src/f1,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      -kk

$ cvs di -U0 f1
Index: f1
===================================================================
RCS file: /home/keno/test-repository/src/f1,v
retrieving revision 1.4
diff -u -U0 -r1.4 f1
--- f1  19 Mar 2002 17:16:38 -0000      1.4
+++ f1  19 Mar 2002 17:18:06 -0000
@@ -1 +1 @@
-$Revision$
+$Revision: 1.4 $
$ # Note that the $Revision$ keyword value is in the working file.
$ # This is wrong, because the source and target of the merge are similar:
$ cvs diff -kk -rB -rBASE f1
Index: f1
===================================================================
RCS file: /home/keno/test-repository/src/f1,v
retrieving revision 1.1.2.3
retrieving revision 1.4
diff -u -r1.1.2.3 -r1.4
$ # and because -kk should be in effect on the working file:
$ cvs st ko
===================================================================
File: ko                Status: Up-to-date

   Working revision:    1.4
   Repository revision: 1.4     /home/keno/test-repository/src/ko,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      -kk
$ # Now clean up and redo the join with c2, the cvs executable with the 
fix.
$ c1 up -C f1
(Locally modified f1 moved to .#f1.1.4)
U f1
$ cat f1
$Revision$

some lines
of text
who cares?

$ cvs st f1
===================================================================
File: f1                Status: Up-to-date

   Working revision:    1.4
   Repository revision: 1.4     /home/keno/test-repository/src/f1,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      -kk

$ c2 up -jA -jB f1
RCS file: /home/keno/test-repository/src/f1,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
Merging differences between 1.1.2.2 and 1.1.2.3 into f1
$ cvs st f1
===================================================================
File: f1                Status: Up-to-date

   Working revision:    1.4
   Repository revision: 1.4     /home/keno/test-repository/src/f1,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      -kk

$

I hope this helps.  I welcome your comments, especially if there's
something wrong with the fix.
--
Ken Olstad



reply via email to

[Prev in Thread] Current Thread [Next in Thread]