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" From: "Peter J. Farley III" Subject: RE: CVS question: Export option to preserve dates? Cc: djgpp-workers AT delorie DOT com In-Reply-To: References: <5 DOT 0 DOT 2 DOT 1 DOT 0 DOT 20001204122315 DOT 025ccd10 AT pop5 DOT banet DOT net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit 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 Precedence: bulk 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. >> 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)