On Thu, 7 Apr 2005 22:05:28 -0400 (EDT) Alan Stern wrote: | On Thu, 7 Apr 2005, Christopher Li wrote: | | > So now when you what to do a "bk pull", you go out and see Greg has any | > new patch on the site or not. If there is, grab it and reapply it. | > (after using your local quilt pop out all the patches first.) | > Of course, you can make a automatic. Maybe we can do some thing like | > "quilt pull". | | One way or another, some simple script ought to suffice for getting the | latest files. | | > Just like you don't have to "bk pull" every time Creg submit something | > to the bk tree. You don't need to do it more often when you switch to | > patches. | | That's not the problem. See below... | | > Let me explain how I see quilt can fit in. We have base line: | > | > linux-2.6.11.tar.gz untar to linux/ | > | > series file: | > linux-2.6.12-rc2.patch # Linus's rc2 patch | > linux-2.6.12-rc2-usb1.patch # Greg's usb1 patch for rc2 | > chris-usb-hack.patch | > | > I do three "quilt push" to apply all the three patches. | > Do my modify of files. "quilt add xxx.c" "quilt refresh" etc to | > build my usb-hack.patch. | > | > Now Greg release 2.6.12-rc2-usb2.patch. | > | > There is more than one way to do it. | > | > You can do "quilt pop" twice, which means "quilt top" should be "linux-2.6.12-rc2". | > Modify series to using rc2-usb2.patch instead. | > Do "quilt push" twice to get to "usb-hack" | > | > Or, if Greg has incremental patch usb1-to-usb2.patch. | > You can "quilt pop" to reach "rc2-usb1", then "quilt fold < usb1-to-usb2.patch". | > So you have usb2 now. | > | > Do "quilt push" again to your continue "usb-hack" development. | | That's all fine, and I'll certainly end up doing something much like it. | Actually I would like to see the incremental "usb1-to-usb2.patch" files, | but Greg's current scripts don't produce them. | | You missed the point of my earlier question, however. What happens when | Greg releases 2.6.12-rc3-usb1.patch? Now all of a sudden my script | doesn't work. It will try to pop back to Linus's -rc2 patch and then | apply Greg's new patch, which will fail dismally. I will need to | intervene by hand (or else write a smarter script).
Well, we'll all have that problem to some degree, so something will be done about it (I predict :). One possibility is to modify the current 'ketchup' script to support lots_of_patchsets, not just the currently supported ones (like -rc and -mm). Proably not the best solution, but should be a workable interim solution. ketchup can back out -rc1 and apply -rc2, e.g. http://www.selenic.com/ketchup/ | > > Also, the individual files in patches/usb for instance -- are these are | > > the original email messages from the submitting authors or have they been | > > sanitized? Are they guaranteed to apply cleanly after all the preceding | > > patches in the series file? Are they guaranteed to apply cleanly without | > > the patches from different $TREEs? | > | > As long as you always "quilt pop" your own change, they should apply clean. | > You always pop out patches to fetch new changes, then push them back in again. | | I don't believe that. Or rather, I don't believe Greg's cumulative patch | files will contain correct copies of all the individual patches. Greg's | script produces several cumulative patch files by applying different | subsets of his complete series. What happens when patches in two | different subsets touch the same part of the same source file? By only | applying the patches in one subset his script is guaranteed to get a patch | failure. --- ~Randy ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
