Thanks, I executed the following thing: find . -type f -exec sed 's/\$revision_history[^\$]*/$Log/g' {} \; This it seems to work well, the output of the SED shows the change, but when I observe the f
Thanks, When I run: find . -type f -exec sed -i 's/\$revision_history[^\$]*/$Log/g' {} \; I get the next error message: sed: invalid option -- i Regards, Paola Jim.Hyslop wrote: Paola Attadio wrote:
Mark, thank you very much!!!!!!!!!!!!!! Best Regards, Paola I get the next error message: sed: invalid option -- i Clearly your sed() doesn't support the '-i/--in-place' option. Something like this s
I get the next error message: sed: invalid option -- i Clearly your sed() doesn't support the '-i/--in-place' option. Something like this shell script should work instead: for f in $(find . -name CV
Please follow the rest of my instructions, reproduced below: -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( htt
Thanks, Paola Jim.Hyslop wrote: Paola Attadio wrote: When I run: find . -type f -exec sed -i 's/\$revision_history[^\$]*/$Log/g' {} \; I get the next error message: sed: invalid option -- i Please fo
You're missing the -i parameter to sed. Without it, it will just send the output of sed to stdout. If your sed does not support -i, then you'll have to redirect the output to a file, and rename the f
[ On Monday, July 9, 2001 at 00:01:01 (-0400), Eric Siegerman wrote: ] Well, with CVS the meaning of "frozen" file is quite a bit different. In the most basic sense what I'm saying is that "-kv" shou
[ 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 "
Back in the 80's when I was starting with rcs I considered $Log$ entries to be cute at first. I soon found out that the entries have these handicaps: - At rev 1.20, the old entries tend to turn into
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 Wednesday, April 25, 2001 at 14:11:01 (-0500), Valarie Flick wrote: ] It would only make sense to remove $Log from all your files. Use of $Log, even with bare RCS, can only provide a confusing d
I also get bitten by $Log$ when merging, but OTOH I still use it. This is partly because some of the projects I work on use "cvs export" to affiliated projects whose only access to log information is
[ On Wednesday, May 2, 2001 at 10:39:47 (-0700), Richard Wesley wrote: ] Teach them to use "cvs log" (and even "cvs rlog" now). Either that or teach them to use GNU-style "ChangeLog" files (which is
<SNIP> I have found that cvs2cl.pl also does a really nice job of generating the logs I need (and I used to like $Log$ when we used rcs), it even tries to generate the 'GNU-style "ChangeLog" files' G
Cederqvist 1.10 states "... CVS is not good at handling $Log$ entries when a branch is merged onto the main trunk. Conflicts often result from the merging operation.". My question is: has anyone figu
Ah, now I get it. Agreed -- except that it shouldn't override "-kb" of course. Or even if there was only one site. I tried this with a couple of open-source things I downloaded, and quickly ran into
Mmm, yes. If it stripped out the values at commit time, and just stored the keywords, all these *#(! merge conflicts would go away. Why is this a problem? I very much prefer it. Suppose, using SCCS o
[ On Sunday, July 8, 2001 at 20:13:40 (-0400), Eric Siegerman wrote: ] The "evil" thing abou RCS keyword design is that they contain their values when stored in the ,v file, and that they contain the
[ On Wednesday, July 11, 2001 at 15:40:04 (-0400), Eric Siegerman wrote: ] If you believe '-kb' should even exist, of course! ;-) Yes, that's another good idea -- and it's probably even been mentione