bugConcurrent Versions System - Bugs: bug #17168, CVS RCS-keyword expansion problem

 
 

bug #17168: CVS RCS-keyword expansion problem

Submitter:  Peter Toft <petoft>
Submitted:  Fri 21 Jul 2006 04:37:23 AM UTC
   
 
Category:  Bug Report Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Release:  1.11.22
Fixed Release:  1.11.23 Fixed Feature Release:  1.12.14
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 28 Aug 2006 08:02:04 PM UTC, comment #5: 

Okay, this appears to work now.  I'm closing this.

Derek Robert Price <dprice>
Group administrator
Fri 25 Aug 2006 08:43:16 PM UTC, comment #4: 

I've fixed this on stable.  I'm still working on merging it into feature.

Derek Robert Price <dprice>
Group administrator
Fri 25 Aug 2006 07:29:22 PM UTC, comment #3: 

You may have misunderstood me.  Currently, update -kk will output `U' for all files, even those which are not changed at all by the operation.

The new change will cause the same to happen with tag updates, but when keywords do exist in the file, then the keywords will also be updated.

Derek Robert Price <dprice>
Group administrator
Fri 25 Aug 2006 06:49:20 PM UTC, comment #2: 

A comment to Dereks comment #1. I fully understand the concern.
I think the proposed change which gives a U at updates is the best wasy to go. The other behaviour I could propose is that the "cvs update -kk" makes a "u" for files which only are updated due to keyword expansion, and "U" for files which are updated due to any other "normal" update change. I look forward to the patch.

Peter Toft <petoft>
Fri 25 Aug 2006 05:37:28 PM UTC, comment #1: 

Okay, I have a patch for this I will probably commit shortly, when `make check' completes.  It has the side effect of looking like it updates everything when any stickies change that may change file contents (options & tags), but then that was the case with updates which changed only the option stickies before.

i.e., where `cvs update -kk' would always:

U file1
U file2
...

regardless of file contents, the same now happens with updates that change the sticky tag.

I'm not sure I like this behavior.  I would hazard that most users would prefer to see a `U' status only when file contents change (not just stickies in the Entries file), but this is a deeper bug to fix and should probably be opened as a second bug/enhancement.

Derek Robert Price <dprice>
Group administrator
Fri 21 Jul 2006 04:37:23 AM UTC, original submission:  

If you have two files

a.txt (two lines) :
--------------------------------
 $Id: $
 $Name: $
--------------------------------

b.txt (one line)
--------------------------------
 $Name: $
--------------------------------

Add those to CVS - check out the module
and run "cvs tag TAG1"

Then
 $ echo "hi there" >> a.txt
 $ cvs commit -m "hi added" a.txt
 $ cvs tag TAG2

If I then run
 $ rm a.txt b.txt
 $ cvs update -r TAG2

Then I see that the label "TAG2" is inserted after the magic keyword "Name" in both files.

If I now continue running
 $ cvs update -r TAG1
Then I see that "a.txt" is updated with version and TAG1 info - however "b.txt" still reads this line only
 $Name: TAG2 $
since TAG1 and TAG2 for the b.txt is the same version.

However if I do
 $ rm a.txt b.txt
 $ cvs update -r TAG2

Then both files will have the wanted TAG2 inserted. I think the current behaviour is unfortunate.

I am also thinking about this in the context of the CVS bug I found recently
http://savannah.nongnu.org/bugs/index.php?func=detailitem&item_id=17032
where I think (read comment #3 from Jim Hyslop) that the MD5 must in both sides use the unexpanded keywords - otherwise things go bad (especially given what I explain above).

This report orginates from http://lists.gnu.org/archive/html/info-cvs/2006-07/threads.html#00053

Peter Toft <petoft>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only logged-in users can vote.

 

Follow 8 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2006-08-28 dprice StatusConfirmed Fixed
    Fixed Feature Release1.12.13 1.12.14
2006-08-28 dprice Fixed Feature ReleaseNone 1.12.13
2006-08-28 dprice Open/ClosedOpen Closed
2006-08-25 dprice Fixed ReleaseNone 1.11.23
2006-08-25 dprice Release 1.11.22
2006-08-25 dprice StatusNone Confirmed
2006-08-24 dprice Dependencies- bugs #17032 is dependent

Back to the top

Powered by Savane 3.13-d3ae.
Corresponding source code