I think it is not going to matter very soon because Linus's git is going to take over the syncing problem. I spend the whole afternoon playing with the git package it is very cool!
I predict we will soon be pulling from the usb.git tree and solve all the version and syncing problem, the infrastructure is there and already kind of working. e.g. the latest git source is in fact in the git.git tree. You have to use older git to pull it out from the tree. Just wait for more custom scripts to sweat it up. Chris On Sat, Apr 09, 2005 at 11:36:27AM -0400, Alan Stern wrote: > Greg: > > When you work on accepting and merging patches, do you use a single tree > for all the changes or do you have separate trees for usb, pci, i2c, and > so on? If you use a single tree then there's no real choice but to export > all the patches together -- cherry-picking the subsets will inevitably > lead to inconsistencies. Personally I wouldn't mind having to download > patches for the multiple subsystems. It's worth it to be sure of getting > a consistent patchset. > > On the other hand, if you really do keep the different areas separate > while working on them (which would force Andrew Morton to do the necessary > reconciliation, right?) then the patches you export also need to be kept > totally separate. Having a single "series" file might work but it > wouldn't be a good idea. > > > I would like to see incremental patches exported in addition to the > cumulative patch file. Here's how it could be made to work. For the sake > of argument I'll assume that all the usb, pci, i2c, etc. patches come from > the same tree. (If not, this scheme could apply to each of the separate > trees.) > > In the top-level directory there should be a file named "base" containing > a single line with two fields, a release name and a patchset increment > number, like this: > > 2.6.12-rc2 5 > > The scripts (on both your end and my end) can read this at startup, and > the increment number can be rewritten by your daily update script. > > In patches/series, your script should maintain subdivisions indicating > where each increment ends. These are in the form of comment lines, > something like: > > #=== 5 > > which would indicate where the patches for increment 5 end and the patches > for increment 6 begin. The update script can automatically append the > appropriate comment to this file in preparation for the next set of > patches. > > Finally, the script could produce incremental patches as well as the > cumulative patch. These can be stored in the top-level directory, with > names like > > gregkh-2.6.12-rc2-4-5.patch > gregkh-2.6.12-rc2-5.patch > > for the incremental and cumulative patches, respectively. (You might even > want to bzip2 them.) > > In a typical run of the update script, here's what would happen. The > script starts by reading the current release name and increment number > from ./base. Let's say the current increment is 5. Then the script > unpacks the base 2.6.12-r2 tree, makes a hard-linked copy, and applies the > -5 cumulative patch. It then makes a second hard-linked copy of that, and > applies all the patches in the patches/series file following the "#=== 5" > line. > > Next the script calculates the diff between the first and third trees, > storing it as the cumulative -6 patch, and it calculates the diff between > the second and third trees, storing it as the incremental -5-6 patch. It > rewrites ./base, updating the increment number to 6, appends the "#=== 6" > delimiter line to patches/series, and erases the -5 cumulative patch file. > Finally the three temporary trees are removed. > > Something like this would provide maximum flexibility, convenience, and > opportunities for automation on my side. My scripts could easily keep > track of what was new and apply only the necessary patches. > > What do you think? > > Alan Stern > > > > ------------------------------------------------------- > 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 ------------------------------------------------------- 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
