From dmurdoch at pair.com  Mon Sep 22 07:07:00 2003
From: dmurdoch at pair.com (Duncan Murdoch)
Date: Mon Sep 22 12:06:17 2003
Subject: [Rd] grep in version 1.8 (PR#4231)
In-Reply-To: <200309211658.10090.deepayan@stat.wisc.edu>
References: <200309210923.h8L9NvJH009422@pubhealth.ku.dk>
	<647smv8672sqfs965mh2pe290onaqs0r5f@4ax.com>
	<200309211658.10090.deepayan@stat.wisc.edu>
Message-ID: <90itmv0o3diihv1v6r2e1f0tpc367r9qt0@4ax.com>

On Sun, 21 Sep 2003 16:58:10 -0500, you wrote:

>On Sunday 21 September 2003 16:50, Duncan Murdoch wrote:
>> On Sun, 21 Sep 2003 11:23:57 +0200 (MET DST), you wrote:
>> >This is not a bug! It works when compiling from clean sources.
>> >
>> >I guess you have unpacked new sources over old sources? Please clean the
>> >directory before unpacking a new version, and try to compile again. A
>> >couple of us ran in the same problem during the last weeks.
>>
>> I don't know if this is what happened here, but this kind of thing
>> also happens when using rsync, not just when unpacking tarballs:
>> rsync won't delete obsolete files.  Anonymous cvs wouldn't have this
>> problem.
>
>rsync should delete files if you give the --delete flag

Yes, but then you end up doing a clean build, because it will also
delete the *.o files, etc.  I don't think there's a concept of
deleting files that were there yesterday but aren't there today.

> (and cvs wouldn't 
>unless you give the -d flag).

-d means something different, it's about which directory to work in. I
notice that I've set a default arg of -Pd, but it's not documented in
my version of cvs as far as I can tell; maybe that's what you're
thinking of?

Duncan Murdoch


[Rd] grep in version 1.8 (PR#4231)
Duncan Murdoch