Re: Making patches: one possible solution.
On Mon, 18 Sep 2000, Amir Karger wrote: > On Mon, Sep 18, 2000 at 02:41:03PM +1000, Allan Rae wrote: > > On Fri, 15 Sep 2000, Amir Karger wrote: > > > > > On Fri, Sep 15, 2000 at 01:48:42PM +1000, Allan Rae wrote: > > > > > > > > I have modified GNU diff to be able to emulate `cvs diff`. This allows > > > > anyone with two copies of a cvs snapshot to modify one and generate a > > > > diff between the two that is the equivalent of what they'd get if we gave > > > > them cvs access. > > > > > > are you sure one couldn't hack > > > together a perl script that would use diff as it already stands? > > > > I tried this with a shell script. It was ugly and it required me to > > identify which files were present in one directory and not the other > > (something diff already does for directory comparisons) and call diff on > > each individual pair of files like: > > diff -u dir1/file1 /dev/null > > Sounds like this worked, even if it was ugly. Almost worked, but was getting hideously complicated and was duplicating all the work done by diff. In fact it was more complicated than diff because it had to work around diff's shortcomings. > Still not as ugly as requiring everyone to use a patched version of > diffutils. (What happens when they upgrade diffultils? What if someone Diffutils hasn't changed in five years -- at least according to the ChangeLog. > else wants them to use a differently patched version?) I guess if you > sent in your patches to the diffutils folks, that might make more > sense. And might even be useful since lots of people in the world who > use diff also want to use it for cvs-diff-like things. As I mentioned in an earlier post diffutils ChangeLog's last entry was in 1994. I was hoping for some feedback while I figure out who to submit my changes to. > > Either way required changes to diffutils sources so I wrote the one that > > made better sense to me. > > I don't understand why the shell script you described required changing > diffultils. Okay, once more. The '-N' option to diff only works when comparing directories. I can't compare directories with diff-2.7 and lyx-devel cvs module because there are some patterns that match files that shouldn't be excluded. For example, "acinclude.m4" can be excluded in all directories except lyx-devel/lib/reLyX/. There are other patterns that should match in only one subdirectory (see *.[cCh] discussion below). Trying to work around the '-N' flag problem by figuring out which files exist in one directory but not another was just duplicating all the work already done in diff to build a list of files to diff (or to exclude) and it added to the complexity. The script was basically rewriting diff as a shell script and only using the file-comparison code from diff to generate the actual patches. Stupid idea. So I extended diff with a few lines of code instead. > Alternatively, if you're worrying about ignoring the right files, why not > write a script that creates a file of files to ignore in the diff, and then > call diff -X? Try: man diff or info diff diff only ignores files whose _basename_ matches a pattern in the exclude file. My first patch to diff was to make it possible to have a pattern like: */src/frontends/xforms/forms/*.[Cch] so that particular files in a particular subdirectory would be excluded. That's when I thought it'd be more useful to just get diff to use a local exclude file (local to each subdir: .cvsignore for example). And before you ask, I did try building a list a patterns to exclude from the .cvsignore files in my shell script and then tried to add the files that were incorrectly matched¹. You'll notice for example that src/frontends/xforms/forms/.cvsignore contains patterns for *.[Cch] with the result that all source files in every subdirectory would match. I tried four different ways² of building the patch and all had similar limitations. Ultimately, I decided diff needed extending to better cope with these difficulties. ¹ Remember you can't remove a patch that shouldn't have been generated so you have to err on the side of caution and then figure out which files should have been included. ² I've just thought of a 5th way that might almost work but it involves recursing through the directory structure and building exclude patterns to be given to `diff -N -X` such that you only do one directory depth at any time (ie. add the subdirectory names to the patterns so that diff won't enter them). This is also overly complicated. Extending diff is still the nicest solution. Allan. (ARRae)
Re: Making patches: one possible solution.
On Mon, 18 Sep 2000, Amir Karger wrote: > I don't understand why the shell script you described required changing > diffultils. > > Alternatively, if you're worrying about ignoring the right files, why not > write a script that creates a file of files to ignore in the diff, and then > call diff -X? > > -Amir > I have a prototype dontdiff file for LyX at home if anyone wants it ... it's not complete though john -- "Tragedy is if I cut my finger; comedy is if you walk into an open sewer and die." - Mel Brooks
Re: Making patches: one possible solution.
On Mon, Sep 18, 2000 at 02:41:03PM +1000, Allan Rae wrote: > On Fri, 15 Sep 2000, Amir Karger wrote: > > > On Fri, Sep 15, 2000 at 01:48:42PM +1000, Allan Rae wrote: > > > > > > I have modified GNU diff to be able to emulate `cvs diff`. This allows > > > anyone with two copies of a cvs snapshot to modify one and generate a > > > diff between the two that is the equivalent of what they'd get if we gave > > > them cvs access. > > > > are you sure one couldn't hack > > together a perl script that would use diff as it already stands? > > I tried this with a shell script. It was ugly and it required me to > identify which files were present in one directory and not the other > (something diff already does for directory comparisons) and call diff on > each individual pair of files like: > diff -u dir1/file1 /dev/null Sounds like this worked, even if it was ugly. Still not as ugly as requiring everyone to use a patched version of diffutils. (What happens when they upgrade diffultils? What if someone else wants them to use a differently patched version?) I guess if you sent in your patches to the diffutils folks, that might make more sense. And might even be useful since lots of people in the world who use diff also want to use it for cvs-diff-like things. > Either way required changes to diffutils sources so I wrote the one that > made better sense to me. I don't understand why the shell script you described required changing diffultils. Alternatively, if you're worrying about ignoring the right files, why not write a script that creates a file of files to ignore in the diff, and then call diff -X? -Amir
Re: Making patches: one possible solution.
On Fri, 15 Sep 2000, Amir Karger wrote: > On Fri, Sep 15, 2000 at 01:48:42PM +1000, Allan Rae wrote: > > On 13 Sep 2000, Lars Gullik Bjønnes wrote: > > > > I have modified GNU diff to be able to emulate `cvs diff`. This allows > > anyone with two copies of a cvs snapshot to modify one and generate a > > diff between the two that is the equivalent of what they'd get if we gave > > them cvs access. > > I know it's a little late to say this, but... are you sure one couldn't hack > together a perl script that would use diff as it already stands, rather than > requiring everyone to recompile their diffutils? I tried this with a shell script. It was ugly and it required me to identify which files were present in one directory and not the other (something diff already does for directory comparisons) and call diff on each individual pair of files like: diff -u dir1/file1 /dev/null since the "-N" only works for comparing directories and I couldn't let diff do that because it didn't ignore the right files. I could have fixed '-N' so it works when diffing individual files but that also requires changes to diffutils. Either way required changes to diffutils sources so I wrote the one that made better sense to me. I might also fix '-N' operation if I get time. > > ¹ I "overclock" the floppy to get 1.9MB disks. > > *That* sounds scary. Not overclocking as such, just formatting to the extreme. 83 tracks of 23 sectors per track. The floppy drive in the machine at uni isn't capable of the ultimate 2MB on a 1.44MB floppy otherwise I'd be using that. Allan. (ARRae)
Re: Making patches: one possible solution.
On Fri, Sep 15, 2000 at 01:48:42PM +1000, Allan Rae wrote: > On 13 Sep 2000, Lars Gullik Bjønnes wrote: > > I have modified GNU diff to be able to emulate `cvs diff`. This allows > anyone with two copies of a cvs snapshot to modify one and generate a > diff between the two that is the equivalent of what they'd get if we gave > them cvs access. I know it's a little late to say this, but... are you sure one couldn't hack together a perl script that would use diff as it already stands, rather than requiring everyone to recompile their diffutils? > ¹ I "overclock" the floppy to get 1.9MB disks. *That* sounds scary. -Amir
Making patches: one possible solution.
On 13 Sep 2000, Lars Gullik Bjønnes wrote: > Juergen Vigna <[EMAIL PROTECTED]> writes: > > | On 13-Sep-2000 John Levon wrote: > | > > | > But to do that would require me to have *two* source trees, because cvs > | > won't know about the new files because I can't do "cvs add". > | > | Well I guess we can add you to the cvs-readonly list AND this means you > | CAN do an add ;) > > yes. Then we'll never be able to accept patches from anyone unless they have cvs access of some description (excluding anonymous cvs). I have modified GNU diff to be able to emulate `cvs diff`. This allows anyone with two copies of a cvs snapshot to modify one and generate a diff between the two that is the equivalent of what they'd get if we gave them cvs access. This way people without anonymous cvs access can work on a snapshot of the source tree (such as Kayvan makes available). It also means anyone with anonymous cvs access can generate patches without Lars having to add them to a growing list of contributors with read-only access. They can do a `cvs update` and fix conflicts just before submitting their patch and everyone should be happy. I have both a patch against diffutils-2.7: (14kB) http://www.devel.lyx.org/~rae/code/arrae-2910.diffutils-2.7.patch.bz2 and a patched diffutils-2.7 tree: (256kB) http://www.devel.lyx.org/~rae/code/diffutil-2.7.arrae-2911.tar.bz2 The patch includes full documentation. I probably went a bit overboard when I added a couple of extra options for making diffs of directories not controlled by cvs. But that's a minor quibble. I'll probably remove those extra bits before submitting it to somebody (the ChangeLog indicates it hasn't been worked on since 1994). Try: ./configure ; make ; make dvi ; xdvi diff.dvi and read the documentation (see concept index under "comparing cvs snapshots" or just go direct to "Comparing Directories") ## Something else that's there that I find useful is: http://www.devel.lyx.org/~rae/code/packcvs This is a shell script that works a bit like the old makepatch script we used to use. It takes from one to three directories as parameters. With one directory it produces a tarball of all the files in a subdirectory _not_ ignored by cvs. I developed this in an effort to reduce the delays when trying to compile on my machine at uni. I previously did a `make maintainer-clean` before making a cvs snapshot to put on a floppy to take home. With two or three directories as arguements a recursive diff will be made of the two directories using: diff -p -N -U 4 -r --emulate-cvs $1 $2 > $3/$patchname So you don't have to remember what the options are for diff to generate a nice patch. ## History 101 === I developed these because I had been struggling to work on LyX at home (no cvs access possible) while minimising the delays when sorting out conflicts on the lame machine I have to use at Uni and to test compile after sorting out those conflicts. I take tarballs home on a floppy disk (just barely fits these days at 1.85MB on a 1.44MB floppy¹) and bring patches back to Uni. I had a modified makepatch script that worked okay but there were a lot of things it couldn't do (ignored too much or not enough for example). So packdir (the redecessor of packcvs) was born to allow me to build tarballs without losing all the compiled object files (the lame machine takes about 45minutes to compile LyX). Then I decided that I couldn't make decent patches using a shell script and modified diff instead. That lead to the final revision of packcvs that supports both packing and diffing cvs snapshots. Allan. (ARRae) ¹ I "overclock" the floppy to get 1.9MB disks.
