John McCabe-Dansted wrote: > OK, I have attached the patch. It is largish because I have run it > through reindent.py and PythonTidy. However, it seems to be the > convention to attach the patches. Is this more convenient than a link > like: > http://www.ucc.asn.au/~mccabedj/keytest_Aug.diff > ?
yes attach the patches please. > Also do you prefer the patches to be broken up into the smallest bits > that still make logical sense? I don't think SVN makes this very easy; > I could git-clone the /keytest branch and use that to track each > individual change. Would this be preferred? generally we require small logical bits, but in this particular case it is not needed, since you are the only maintainer and it would be rather pita to commit every single bit separately, when you dont have commit access yourself ;) > This patch additionally includes "cache-bisect". Cache-bisect is > roughly based on git-bisect, but uses SVN and caches every build tree > to maximize performance. The idea here is that if the first few tests > happen very quickly, and give plausible results, you can have > confidence that you can just leave it running. Without that confidence > I'd be continually thinking "I the bisect still working, maybe I > should check" so the bisect would be taking up my mental space. With > cache-bisect, I can fire-and-forget, leaving the CPU to do the menial > tasks while I think about other things. Additionally caching the > build-trees cuts down on the amount of bandwidth required on the SVN > server > It uses three levels > 1) At the bottom level, it bisects much like git-bisect > 2) At the second level, it bisects, but only over cached revisions. > 3) The the top level it does what I refer to as a "multisect". The > idea is that you may not know which revision was a good revision, and > picking revision 1 as the "good" revision is not only mildly wasteful > but is likely to produce misleading results. Instead it starts > stepping backwards, first trying 1.6.0, and then going backwards > through trunk. such description should go into cache-bisect.sh in next patch... unfortunately you sent patch which doesn't apply, probably you are diffing in some wrong tree: 1 out of 1 hunk ignored -- saving rejects to file lyx_make.sh.rej The next patch would delete the file replay.sh, which does not exist! 1 out of 1 hunk FAILED -- saving rejects to file autolyx.rej The next patch would delete the file test.py, which does not exist! pavel
