From: Daniel J S. <dan...@ie...> - 2006-03-02 19:06:09
|
Lars Hecking wrote: > > >>OK. Exactly what format of diff-ing should I use, and against what, >>to create the patch? A cvs diff against the head? A diff against 4.0? >>What options on the diff command? I'd say work against the most recent version in CVS for your own benefit of having the latest of everything and won't have a major update when 4.2 comes out. You'll invariably have hunks rejected at some point that require fixing, so might as well work against the most recent. >> >>Also, there are some new test scripts and test data files to demonstrate >>cases where the existing fits do the wrong thing, and that the changes make >>it do the right thing. How should that be handled? It appears that the patch >>submission page on sourceforge expects only one file per patch. Should I >>tar together the diff output and the new test scripts and data files? Or make >>multiple "patches"? > > > You have two gnuplot directory trees: the original, be it off cvs or > 4.0, and your edited tree. Then you just run > > $ ls > gnuplot-x.y.z.orig gnuplot-x.y.z > $ diff -ur gnuplot-x.y.z.orig gnuplot-x.y.z >foobar.diff > $ gzip/compress/whatever foobar.diff > > and upload the gzipped diff file. > > Or, if you made the changes in your checked out copy directly, use > "cvs diff -u". But then you need to exclude the CVS directories. > > The cleanest way is probably: > > - In the checked-out directory, perform a full build and then "make dist". > - Unpack the dist file somewhere else and rename it gnuplot-x.y.z.orig. > - Unpack the dist file again in the same directory (gnuplot-x.y.z). This > is where you make your edits. I do pretty much the above, but I get a copy from CVS and put it in, say, gnuplot-newfit. Then in the gnuplot-newfit directory where CVS has placed "gnuplot" I > cp -a gnuplot gnuplot-cvs > cp -a gnuplot gnuplot-mod The names are a preference thing, the basic idea is three copies: an untouched CVS version, a source tree modifications only version and a compiled version. In gnuplot-mod is where changes go. In "gnuplot" I will create symbolic links to the files in gnuplot-mod that have been changed. Compile, edit and test everything in "gnuplot". What this does is prevent extraneous and hidden files (from editors) from building up in the "gnuplot-mod" directory. Otherwise bloated files appear in the diff sometimes without paying attention. > diff -ur gnuplot-cvs gnuplot-mod > gnuplot-newfit-ddmmmyyyy.patch e.g., gnuplot-newfit-2mar2006.patch. Also, I'd suggest not leaving in old, commented out text or placing your initials next to changes you've made. That's cruft that will only build up. I don't think people generally do that. (The patch file is often the place to go first for developers so they can see precisely what the changes are; no need for programmer tags.) The time to leave your initials is when there may be some tricky part with a comment, or something that needs to be fixed in the future because of something else in gnuplot that needs to be addressed. Leaving your initials will then help others find the person to ask when it comes time to fix the problem. Oh, yeah, then when it comes to updating your patch against the latest CVS, repeat the "gnuplot/gnuplot-cvs/gnuplot-mod" thing and then from within "gnuplot-mod" do > patch -p1 --dry-run < ../gnuplot-newfit-ddmmmyyyy.patch > patch -p1 < ../gnuplot-newfit-ddmmmyyyy.patch and go about fixing and discarding all the hunk reject files "<file>.rej". Dan |