mirror of
https://git.lyx.org/repos/lyx.git
synced 2024-09-19 22:40:26 +00:00
8a7b05f57c
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg154502.html git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@31495 a592a061-630c-0410-9148-cb99ea01b6c8
28 lines
1.3 KiB
Bash
Executable File
28 lines
1.3 KiB
Bash
Executable File
#!/bin/bash
|
|
|
|
# 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 "Is 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.
|
|
|
|
KT=$(cd $(dirname "$0") && pwd)
|
|
$KT/cache-bisect.py "$@" | tee out/cache-bisect-$USER.log
|
|
|
|
|