From: "Tim Van Holder" To: Subject: RE: CVS question: Export option to preserve dates? Date: Tue, 5 Dec 2000 18:28:34 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <5.0.2.1.0.20001204194517.025a0b20@pop5.banet.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id MAA28370 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 [I sent this earlier today, but the mailing list bounces mail I send from my work address, so I'm resending it now] Peter J. Farley III wrote: > 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 I see - guess I've gotten too used to my cable/leased line connection. > 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 You wouldn't be - the anonymous cvs is read-only access. Checkouts/Exports are possible, commits aren't. > 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. Ouch. I remember those days at university, when 23K/s seemed enormously fast. > 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. > > What you could do is this: $ cvs checkout djgpp This gets you your working copy (after a few pots of coffee and a good night's sleep). I suggest using co (checkout) instead of export; this will allow you to make the final patch online once you've completed testing. All files have the date they were checked in. $ zip -9r djgpp-tree.zip djgpp $ zip -d djgpp-tree.zip */CVS/* This strips out CVS dirs. $ mv ./djgpp ./djgpp-cvs $ unzip -x */ djgpp-tree.zip $ rm djgpp-tree.zip Now you have two djgpp trees: djgpp and djgpp-cvs. You can make changes to djgpp-cvs, and use 'diff -r djgpp djgpp-cvs' to make test diffs. If your current changes were made against djdev203, simply make a diff between stock djdev203 and your local files, then apply the diff to the djgpp-cvs tree (there may be some patch failures, but they should be easy enough to resolve). 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. > 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. As said above, what's undesirable about making a diff between djdev203 and your sources, then applying that diff to the sandbox? 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. Tim Van Holder