Thanks, Mark D. Baushke wrote: --BEGIN PGP SIGNED MESSAGE-- Hash: SHA1 I can use the LocalKeyword, but I can't use Log in this definition. I don't have any problems with the others keywords. Let see,
No. Look at src/rcs.c RCS_setlocalid() for how it is parsing the line. Anything up to the next '=' sign that is a a valid character will be okay. This allows for many iso-8859-1 characters to be in t
<SNIP> <SNIP> You are looking for the RCSkeywords, in particular $Log:$ [1]. however I think many people[2] would advise you against using them, as they cause problems[3] when merging[4], and you ca
Hello Bret, Yes, this has to be run for every file to be changed. Anyway, you can use wildcards, so a cvs admin -kk *.c *.cc *.h makefile and so on works very good. Even if you forget to change a fil
There are a couple of advantages of storing RTF instead of .doc. You _might_ get slightly more efficient file storage using .RTF. If you check in without -kb, then you could use the RCSkeywords ($Id
If you are not too worried a few odd merge conflicts, you could always add the $Revision$ or $Id$ keywords to a comment in your source code and the write the canonical 5 lines of Perl to snag the rev
Hi Gu, These are intermediate files used by C++ to make builds quicker that you don't need to keep in CVS. You're better off adding them to your .cvsignore file instead. HTH, Matthew Herrmann -- VB6/
Gu, I believe these are all binary files. You should have added them to cvs with cvs add -kb so that keyword expansion was turned off and the file was recognized as binary. By default cvs assumes fil
A long time ago, we started a new branch that has since become the main development line. A few changes occurred on the trunk as well but that line has effectively died out. Now I would like to merge
Some systems distinguish between text and binary file (e.g., Windows) and some do not (e.g., Unix and Linux). If your system(s) do not distinguish between text and binary, you can import, add, checko
If the file is in $CVSROOT/CVSROOT, then you need to put the name of the file in $CVSROOT/CVSROOT/checkoutlist. See http://www.cvshome.org/docs/manual/cvs_18.html#SEC176 If the file is in some other
[ On Wednesday, June 5, 2002 at 10:37:57 (-0400), Larry Jones wrote: ] If you do that then it's critical to use "-ko", at least when managing sources that include RCSkeywords There's also a potentia
I'm not sure it's only two... a) eol conversions (at leat three types of these, neglecting fixed-record systems) b) mergeable vs. non-mergeable files c) files in which RCSkeywords should be expanded
Mark, I think you are using cvs in local mode. If you where using it in a client/server mode, cvs would have the tmp files a location on the server (the /tmp by default with pserver). Since you are i
Output from a trigger script: use Cwd; use strict; use Carp; my $pwd = cwd(); open (F, ">/tmp/junk/test.txt") or croak ('can not open /tmp/junk/test.txt'); print F "PWD: $pwd\n"; print F map { "$_\n"
I just did some testing, and modifying the server tmp copies is a real bad idea, like Dennis said. But it is good that CVS makes the to-be-commited files available (whether or not by design) to the t
Mark, Is this really a good idea? If you do what you are proposing, after you commit a file, changes will be made to the file (unbeknownst to you) and I suspect your local copy will immediately be ou
It would indeed avoid the merge problem (or at least reduce it) ... but it's *impossible* to compute in the presence of branches. CVS doesn't keep around enough info to know which revisions of which
[ On , July 7, 2001 at 18:22:09 (+0100), James Youngman wrote: ] Why not just add "cvs log" to the release process?????? You can even use "rcs2log" to get ChangeLog-style files. Using "cvs log" (or "
We have a similar situation where multiple releases are being developed concurrently and commits to one branch are required to be merged into several other branches. I created a wrapper script 'check