delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2000/12/04/15:42:39

From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To: <djgpp-workers AT delorie DOT com>
Subject: RE: CVS question: Export option to preserve dates?
Date: Mon, 4 Dec 2000 21:44:57 +0100
Message-ID: <NBBBIOJKJBNCHJBEKHLOAECLCCAA.tim.van.holder@pandora.be>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <5.0.2.1.0.20001204122315.025ccd10@pop5.banet.net>
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id PAA00594
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

> ??? How does one run a local test make when the "original" dates are 
> not available?
Basically, you just do a checkout - the timestamps you get are the timestamps of the file's checkin (but they DON'T matter to cvs; you could run 'find -type f - exec touch {} ;' and cvs would still function normally (it would simply update it's idea of each file's timestamp, as kept in CVS/Entries, the next time you run 'cvs status').
So you can just do the usual stuff (make, editing, etc). And when you're done, all you need to do is 'cvs diff' and voilą: instant patch.
djlsr203 shouldn't really come into it, unless you're trying to make a 2.03-to-CVS diff, in which case you're better off using 'cvs diff' too; I expect there'll be a tag for the 2.03 release (checking... yup: v2_03)

So, assuming CVSROOT is pointing to DJ's anoncvs server:

$ cvs -z9 co djgpp
$ cd djgpp
$ cvs status -v copying
-> this'll show the available tags
$ cvs diff
-> shows diffs between files on server and local files
$ cvs diff -r v2_03
-> shows diffs between files on server as they were at the time of the
-> 2.03 release, and local files
-> e.g. 'cvs diff -r v2_03 readme.1st' will show you a typo was fixed

So after editing files locally, if you wanted to post a patch, you'd
probably do run:

$ make
-> to make sure your local files actually compile
$ cd /top/of/djgpp/sandbox
$ cvs update
-> just to make sure you're up-to-date; make sure to resolve conflicts
-> if cvs reports any.
$ cvs diff > ../my.patch

> I found out what my trouble was -- I had to add the -w option to diff 
> to ignore CR's at EOL.  The CVS files seem to all have CRLF-delimited 
> lines, while the djlsr203.zip has (mostly) LF-delimited lines.  Perhaps 
> the cvs that I'm using (the one from the cvs site for windows) is 
> producing this?  Is there a way to tell cvs *not* to use CRLF, but just 
> LF?  Or are the files stored in the repository that way?
No, it's an unfortunate artifact of the NT port of CVS (and I believe the DJGPP package I made also had this problem): it writes text files as text (surprise, surprise), resulting in CRLF on DOS. 'cvs diff' doesn't care though - when diffing a text file, it will read data in text mode as well.

Hope this helps,

Tim Van Holder

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019