В большинстве современных инструментов контроля версий есть команда для поиска изменений, которые привели к ошибке путем бинарного поиска (деления пополам) по истории. Такая команда может быть встроенной или предоставлена как расширение или плагин. Примеры включают git-bisect в Git, " hg bisect" в Mercurial (ранее доступный как hbisect расширение) и bzr-bisect плагин для базара.
Задача состоит в том, чтобы сделать это автоматически или полуавтоматически, даже при наличии нелинейной истории (точки ветвления и слияния). В общем, цель состоит в том, чтобы найти «плохую» ревизию за минимальное количество шагов, или, более подробно, найти коммит для тестирования, который, по возможности, делит график коммитов для тестирования (DAG коммитов) пополам. Эта проблема, я думаю, решена очень хорошо.
Но есть проблема с непроверяемыми коммитами , например если какой-либо код ревизии даже не компилируется, или если он компилируется, он не запускается / не запускается (или обнаруживает ошибку, не связанную с той, которую вы ищете). Это означает, что вместо того, чтобы просто пометить коммит как «хороший» или «плохой», теперь у вас есть три возможных состояния:
- хорошо - ошибки нет
- плохо - глючит поведение
- неизвестно ( не проверяется ) - неизвестно, присутствует ли ошибка
Некоторые системы контроля версий (SCM) позволяют вам «пропустить» такие коммиты, обычно переходя к родительской ревизии как к следующей для проверки.
Вопросы:
Если вы имели дело с такой ситуацией, то есть вы использовали разделение пополам и наткнулись на непроверяемые ревизии, каков ваш опыт распределения таких непроверяемых коммитов? Происходят ли они изолированно (один непроверяемый коммит) или они появляются в диапазонах (ревизии a..b непроверены)? Вы оказались в ситуации, когда вам пришлось пропустить коммит после коммита?
Существует ли какая-либо математическая модель (например, для простого деления пополам списка / линейной истории и даже для разделения пополам произвольной DAG ревизий) или алгоритм (возможно, эвристический), который позволяет оптимизировать пропуск непроверенных коммитов. Цель снова состоит в том, чтобы минимизировать (в среднем) количество версий для тестов при наличии непроверяемых коммитов (или несвязанных ошибок).
Используете ли вы систему контроля версий, или какое-либо дополнение / расширение / плагин для системы контроля версий, или какой-либо сторонний инструмент, который реализует такой алгоритм, помимо того, что он позволяет просто «пропускать» не тестируемые коммиты, перейдя в соседская ревизия? Что это за VCS или инструмент? Какой алгоритм он использует (если вы это знаете)?
Надеюсь, это приведет к еще более простому (полу) автоматическому поиску ошибок ...
Добавлено 06.06.2009:
При использовании расширенных возможностей Git существует одна ситуация, когда вы можете иметь целую ветку непроверяемых коммитов (или, по крайней мере, трудно тестируемых), а именно, когда вы используете объединение " subtree " объединить истории двух отдельных проектов (например, полное ядро Linux с некоторыми драйверами, разработанными отдельно с помощью слияния «поддерево»). Это необходимо учитывать при разработке алгоритма для обработки непроверяемых коммитов: в нелинейной истории может быть целая ветвь непроверяемых коммитов, и алгоритм должен учитывать топологию (в некоторой степени).