Mail Archives: djgpp-workers/2000/12/05/12:26:04
[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.
>
> <Terrific, simple instructions snipped>
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
- Raw text -