Me too. I think it would be best to add an RCS newphrase in the archive file for storing signatures. Old versions of CVS and RCS which don't understand the newphrase would even ignore it. See the rec
Use the command 'man rcsfile' For commitid, I used { commitid id; } and the id itself used in CVS is a base62 encoded text. It would have been more efficient to use a base64 encoded value for the id
Rahul and Patrick, Thanks for submitting the patch. Our development manager has had a look at it and found that it is unsuitable for inclusion in CVSNT, however a simpler solution has been found and
NO! One wants to be able to query based on this; more importantly, CVS itself needs to be able to do so to implement merge-tracking. The RCS file format is extensible; this shouldn't be a problem. I
<SNIP> Ok, unfortunately the way open source documentation works often is "Now that you understand the problem please describe it in the doc for the next person and submit the doc patch".... Ok, now
Clarification: keywords (e.g. $RCSfile: $ $Name: $) are RCS entities .... Hmm. Now that I look it up (http://www.badgertronics.com/writings/cvs/keywords.html), this is incorrect. $Name: $ seems to be
[ On Friday, April 12, 2002 at 12:14:14 (+0200), Jon Krom wrote: ] Which is a very bad idea when using CVS. Revision numbers in CVS are "for internal use only". Do not muck with them, and especially
Lund, CVSNT has recently added definable keywords, this may be more what you are looking for. CVSNT is free/GPL (just like CVS) and runs on Windows/Unix/Linux/Mac etc. You will need a testing release
[ On Thursday, March 21, 2002 at 10:26:07 (-0500), Larry Jones wrote: ] Ah ha! There's the comment (and code) I was looking for! Thanks for the pointer! This part of the comment is very telling w.r.t
/* The checkin succeeded. If checking the file out again would not cause any changes, we are done. Otherwise, we need to check out the file, which will change the modification time of the file. The o
The extension to the RCS format (ie. the data-storage layer) should be a general one. It should provide for storing an arbitrary set of named attributes (ie. key/value pairs) per revision. There shou
The rinfo program will parse the RCS files and provide info about each revision. If you need something it doesn't give then it's easy enough to add it. Once you have mapped out the structure of the R
On Thu, Mar 21, 2002 at 08:15:03 -0800, Noel Yap sent 0.9K bytes: It certainly does work for changes made with the commitinfo script - an undocumented feature, perhaps. Scott -- People say I live in
Thanks for clearing this up. This comment also indicates that the checkout is specific to updating RCSkeywords so it wouldn't work for changes made by a commitinfo script. Noel _____________________
I implement $DateLocal$ keyword expansion using strftime(). Is this a bad idea? -- KOIE Hidetaka <address@hidden> Index: rcs.c == RCS file: /home2/cvsroot/ccvs/src/rcs.c,v retrieving revision 1.248 d
Dear all, RCS used to have a few tricks I used every now and then, that I haven't found back in CVS yet. 1. When checking-in a file into RCS, one could instruct RCS to use The RCSkeywords in the fil
On Thu, Mar 21, 2002 at 12:20:39 -0500, Larry Jones sent 0.5K bytes: Yeah, I understand that keywords expansion is required for my kludge to work, and that what I am doing is a definitely a kludge. I
(under a update See my reply to your 'Inaccurate documentation re "cvs tag"'. commit does an update to keep things consistent between your sandbox and the repo when it gets done. See my reply under
Thanks for the suggestion, I have implemented commitinfo script to prevent someone from using $Name$, but I'm curious as to why $Name$ works differently from the other keyword expansions. Why does th
the rcsfile-manpage Yes, the basic parsing shouldn't be too difficult. However, the need to undiff and rediff, whilst respecting branches, is where the complexity arises. actually I don't think there