On Thu, Apr 07, 2005 at 03:22:51PM -0400, Alan Stern wrote: > On Thu, 7 Apr 2005, Greg KH wrote: > > > > And will you be sure to post a message informing us every time > > > something like that happens? > > > > Why? I never did that before. > > It was never necessary before. Changes to the gregkh-2.6 BK tree were > always monotonic and I could synchronize simply by doing "bk pull". Now > there's the possibility that a large number of patch files might suddenly > vanish because you've switched over to a different base. I'll need to > know when that happens so I can switch over too.
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". 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. > > > I'll CC: people on their patches when I > > send them to Linus (not sure how that will happen due to him changing > > the way he works too.) I'll just keep around the stuff that didn't make > > it in, like I used to do before with bk. > > > > Is that a problem? > > I'm trying to figure out how to make all this work most efficiently from > my end. For instance, when I want to synchronize with kernel.org, am I > better off: > > Downloading the cumulative usb-2.6.12-rc2.patch file? > > Downloading all the cumulative patch files? > > Downloading the patches/series file plus all the individual > patch files? > > Downloading the patches/series file plus only the individual > patch files I don't already have? > > The first is easiest, and while the fourth is clearly better than the > third I don't have any tools to handle it automatically. (rsync?) > However applying a large cumulative patch file means I have to recompile > all the files it touches, even though they may not have changed since the > last time I synchronized. Using patch -T or -Z doesn't seem very safe, > or am I wrong? 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. > > 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. Hope that helps. Chris ------------------------------------------------------- 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
