delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2000/12/04/20:28:57

Message-Id: <5.0.2.1.0.20001204194517.025a0b20@pop5.banet.net>
X-Sender: usbanet DOT farley3 AT pop5 DOT banet DOT net
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Mon, 04 Dec 2000 20:23:32 -0500
To: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
From: "Peter J. Farley III" <pjfarley AT banet DOT net>
Subject: RE: CVS question: Export option to preserve dates?
Cc: djgpp-workers AT delorie DOT com
In-Reply-To: <NBBBIOJKJBNCHJBEKHLOAECLCCAA.tim.van.holder@pandora.be>
References: <5 DOT 0 DOT 2 DOT 1 DOT 0 DOT 20001204122315 DOT 025ccd10 AT pop5 DOT banet DOT net>
Mime-Version: 1.0
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id UAA25031
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

At 09:44 PM 12/4/00 +0100, Tim Van Holder wrote:
 >> ??? 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)

Yes, but that assumes one *wants* to do online diffs.  I just want to 
be able to do local diffs to a current base.  I don't really want to 
re-connect to my ISP every time I need to make up a test diff.  And I 
don't want to checkout the files, either, because I do not feel 
competent enough at cvs to be *trusted* to check anything in.  I just 
want to export them and generate local diffs, and then submit the patch 
file to the djgpp-workers list for those who *can* be trusted to update 
the real source.

And at dial-in speeds of only 50K bps or so, *nothing* I run online is 
"instant".  More like, go brew a pot of coffee and maybe it will be 
done when you get back.

Plus, not having the original dates means that I now I have to go back 
and somehow patch my changes into the "updated" sources, instead of 
just being able to diff the newer sources and my tested (on a base of 
v2.03) changes, in order for a locally-run make to recognize *my* 
changes to the files.

<Terrific, simple instructions snipped>
 >> 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.

Well, it does explain the problem.  I had already started to make up a 
shell script to copy the date of the files from the v2.03 source zip to 
the ones with the same name in the exported copy in my sandbox area, 
but I realized after starting on it that it was a mistake, since any of 
those files may be the ones that were updated since v2.03.  With the -w 
option, at least a local diff sees only the files that have really 
changed since v2.03.  I could (and maybe I will) update the script to 
run dtou on all of the files in the sandbox, which would at least 
eliminate the use of -w.

 >Hope this helps,

Tim, it certainly does.  Thank you for those excellent instructions, 
they're *almost* enough to make me feel I understand what I'm 
doing.  The failure is mine, not yours.

<*Sigh*> And I thought I was almost done with these changes...

---------------------------------------------------------
Peter J. Farley III (pjfarley AT dorsai DOT org OR
                      pjfarley AT banet DOT net)

- Raw text -


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