Message-Id: <5.0.2.1.0.20001205182955.03482460@pop5.banet.net> X-Sender: usbanet DOT farley3 AT pop5 DOT banet DOT net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 05 Dec 2000 19:07:42 -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 20001204194517 DOT 025a0b20 AT pop5 DOT banet DOT net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 06:28 PM 12/5/00 +0100, Tim Van Holder wrote: > [I sent this earlier today, but the mailing list bounces mail I > send from my work address, so I'm resending it now] >If you need test diffs to run against 2.03, use this sequence >instead: >$ cvs checkout djgpp >$ mv djgpp djgpp-cvs >$ cvs export -r v2_03 djgpp >This gives you the same situation as above, but djgpp now holds the >sources as checked in at the time of the 2.03 release. >I don't see any particular reason to do this though; not only does >it double your required online time (for the two downloads), but it >would probably be easier for Eli or whoever to apply diffs made >against a recent snapshot than diffs made against stock 2.03. Understood. And I do have a local copy of v2.03 from djlsr203.zip from which to produce an initial diff to apply to the checked-out sandbox. >As said above, what's undesirable about making a diff between >djdev203 and your sources, then applying that diff to the sandbox? Nothing at all, it's exactly what I have realized that I need to do, since some of the changes I have yet to make depend on changes already made by others, and those changes are not in the v2.03 distribution. I did not take that into account when I originally made that statement. >If I'm still not properly grokking what you're trying to do, feel >free to set me straight. I'm still not sure why dates are so important >to you; diff doesn't care about them - it just compares file >contents. I was concerned about doing a make in a sandbox derived from a tree made with export. Since the "current" (i.e., last checkin) dates are not stamped on the exported sources, any part of the make that depended on certain files being earlier dates than other files would fail, or would cause unnecessary or unwanted element builds (e.g., if a .c file has an earlier date than the .y file that *can* be used to build it, but you don't have bison available to do the .y build, or it's a buggy version, etc.). I was just anticipating possible problems. I took your earlier advice and did a checkout, and that looks just fine to work with, except for the ubiquitous */cvs/* files. BTW, the instructions you gave above to strip the */cvs/* files out of a zipped tree use "zip" and "unzip" commands. Would you please tell me what/whose version of zip/unzip they are? Aliases for gzip/gunzip, I hope? If not, where can I get a copy? Thanks for your kind instruction of this humble pupil, Tim. I really appreciate the clarity and simplicity of your replies. You're grokking my needs just perfectly. --------------------------------------------------------- Peter J. Farley III (pjfarley AT dorsai DOT org OR pjfarley AT banet DOT net)