[Michael Hudson] > For patches that > > cvs up -j blah -j blat file > > can handle, I have a setup that make porting them the work of seconds. > It takes a little while to set up, so I batch them. Maybe waiting for a change to show up in the trunk is a better way to go. Since I was making the trunk change "live", and wasn't going to check anything in before everything worked on both trunk and branch, -j was impotent (in the way I happened to do this). Regardless, it won't work for *this* patch if it's desired in 2.1 (too much has changed). > I don't run the tests for every checkin this way so I guess I risk > pain -- if I plough through 20 or so fixes in a run and find > somethings broken, working out what did it could be entertaining. > Hasn't happened yet, though. In this particular case, we don't have any machinery in the test suite for detecting unbounded process growth, and I don't know a low-effort way to add some that would actually work x-platform. I did have a "by hand" test to run, which runs forever while I stare at the output of a Windows process-size sniffer. So this particular case required running tests manually, and if "it breaks" (in the sense of not clamping process growth) someday, that won't be detected automatically. > What I'm saying is, if getting fixes into the tree is awkward for you, > don't worry about it /too/ much. It would have been easier if I checked in the trunk changes first before bothering with the 2.2 branch. Still, the primary point stands: when writing the code goes fast (as it does with most bugfixes), and if everything is great, it still takes more than N times as long to stick a fix into N releases. So batching 'em up may be an expedient idea, as it certainly allows amortized some of the expenses (it all adds up! and, e.g., doing a cvs up over the network in a branch burns the same amount of time whether you're doing the update in preparation for backporting 1 fix or 1000). > I want to fiddle my scripts a bit, but they should appear in Tools/ at > some point... Cool!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4