Избегайте случайной фиксации определенных изменений в файле в Subversion

Question

Проблема

Я просто случайно внес изменение в файл, который предназначен только для устранения проблемы. В результате я скорее испортил текущую версию нашего программного обеспечения, поскольку случайно отключил важные функции: - (.

Поскольку это происходит не впервые (и я не единственный, с кем это случилось), мой вопрос:

Существует ли практический механизм предотвращения случайных изменений, которые вы не хотите совершать?

Я думаю об изменениях, когда вы уже знаете, что не хотите их фиксировать при их создании (например, об изменениях, помогающих отладке или тестировании).

Мой текущий подход:

Обычно я просто отмечаю такие изменения // FIXME: DEBUG, чтобы они были перечислены и выделены в Eclipse. Однако этого недостаточно, поскольку я все еще могу зафиксировать эти файлы.

Мне бы хотелось, чтобы какой-нибудь механизм, который сообщает Subversion «не фиксировать этот файл в этом состоянии», - может быть, специальный комментарий или какое-либо свойство файла (например, «заблокировать этот файл для фиксации»). Есть ли такой механизм?

Единственное решение, которое я могу придумать, - это иметь ловушку перед фиксацией, которая сканирует специальные комментарии, но я бы хотел избежать необходимости настраивать серверную часть, если смогу помочь.

Answer 1

Вы можете добавить хук предварительной фиксации к Subversion, который проверяет определенное свойство Subversion, например, mycompany:dontcommit.

Затем вы можете установить это свойство в локальном файле, и сервер Subversion отклонит файл, если вы когда-нибудь попытаетесь его зафиксировать.

Мы использовали эту систему в течение некоторого времени, и поверьте мне, она спасла меня пару раз. ;)

Answer 2

Этот ответ специфичен для Visual Studio, но я сильно подозреваю, что нечто подобное можно было бы сделать для Eclipse.

В Visual Studio с использованием C # я выполняю всю свою разработку и большую часть тестирования во время компиляции в режиме отладки.Режим отладки компилируется с определенным флагом DEBUG.Затем, всякий раз, когда я пишу тестовый код, который может что-то сломать, я добавляю следующее:

#if !DEBUG
#error DEBUG is not defined. Fix the above lines, which are for debugging only.
#endif

Затем я проверяю, что перед выпуском релиза в производственную среду я переключаюсь с компиляции в Debugрежим компиляции в режиме Release.Режим Release не определяет символ DEBUG, поэтому компилятор генерирует ошибку.

Это, конечно, не сработает, если вы не привыкли всегда выпускать в режиме Release.Это также не сработает, если вы не помните, чтобы копировать и вставлять этот код всякий раз, когда вы что-то ломаете.Но на самом деле, любое решение будет иметь подобные проблемы.

Обратите внимание, что с моим решением я все еще забываю и фиксирую испорченный код в репозитории SVN.Однако, пока все следят за процессом выпуска, как только кто-то собирается создать выпуск, он получает ошибку компиляции и обнаруживает проблему.

Answer 3

Иногда лучшее, что вы можете сделать, это написать модульный тест, который настраивает среду так, как вы хотите, и позволяет тестировать этот сценарий, а затем, когда вы фиксируете его, он начнет проверять это автоматически и часто.1002 * Мне также нравятся другие идеи использования флага, например if (отладка), который вы можете включить во время выполнения только тогда, когда он вам нужен.

Но чтобы ответить на ваши вопросы, вот предварительная фиксацияскрипт, который работает для этого.Он просматривает все файлы, которые вы делаете, и если файл содержит текст «DoNotCommit», он выдаст вам ошибку.Я планирую размещать подобные комментарии всякий раз, когда я делаю изменения только для тестирования.Приятно, что вы можете поместить этот комментарий в любой тип файла, и он всегда будет ловить его.

#!/bin/bash
function die {
  >&2 echo $1
  exit 6
}

REPOS="$1"
TXN="$2"

SVNLOOK=/usr/bin/svnlook

# Make sure that the log message contains some text.
#$SVNLOOK log -t "$TXN" "$REPOS" | \
#   grep -q "[a-zA-Z0-9]" || die "Blank message not allowed"

# make sure the files do not contain DoNotCommit
# this runs svnlook changed which shows a list of adds, updates and deletes, for each file it calls svnlook cat to look at the contents
for file in `$SVNLOOK changed -t "$TXN" "$REPOS" | awk '{print $2}'`; do
  # skip over file that ends in / because it is a directory
  if [[ "$file" != */ ]]; then
    $SVNLOOK cat -t "$TXN" "$REPOS" "$file" | grep -q -i "DoNotCommit" && die "Found text DoNotCommit in $file";
  fi
done

# Exit on all errors.
set -e

# uncomment this to make it always fail at the end while testing changes to script
#>&2 echo failing at end
#exit 3

# All checks passed, so allow the commit.
exit 0

Answer 4

Одним локальным решением является управление файлами с помощью наборов изменений.

Это работает для нашей организации.

У каждого разработчика есть набор изменений "local-do-not-commit", гдемы помещаем наши отладочные изменения.

У нас также есть «реальный» набор изменений, который мы намерены зафиксировать.

Это требует, чтобы вы переместили «неназначенные» изменения в правильный набор изменений.

Мы используем Eclipse / Subversive.Это позволяет вам зафиксировать определенный набор изменений из Eclipse.

Если вы используете командную строку SVN, для этого есть опции «списка изменений».

Примечание: Subversive »наборы изменений"не такие, как SVN" списки изменений ".(Не уверен, почему это так. Но это раздражает.)

Answer 5

1) Отладочная инфраструктура. Если у вас все время есть операторы, но они отключены, то не имеет значения, проверяете ли вы их. На самом деле, вы хотите проверить их. При отладке включите отладку. Вы также можете сделать ваши временные обходные пути зависимыми от флага отладки. Например. когда вы хотите пропустить часть кода:

if {$debugflag < 50} {
    doImportantFeature
} else {
    doMyDummyTestThing
}

2) Сделайте процесс сборки более надежным. Многие компании проводят автоматические сборки и даже автоматические установки каждую ночь, но мне это кажется неправильным. Не столько частота, сколько авто -.

3) Использовать распределенную систему контроля версий. Таким образом, вы можете зафиксировать отладочную информацию локально, если хотите / забудете, но вы будете проверять все это снова, когда будете отправлять ее в главный репозиторий.

Answer 6

Мое решение удобно, когда вы делаете много временных изменений кода в своем рабочем пространстве, но не намерены совершать все в конце дня, когда вы уходите. Это то, что я делаю каждый день.

Я создал собственную аннотацию под названием @Tempcheckout в своем проекте. Это я аннотирую те классы, которые меняю только для временных целей. После фиксации в конце дня (которая может быть где-то, например, 20-30 файлов), у меня есть задание Jenkins, которое запускается коммитом, и это сканирует все классы в кодовой базе для аннотации и отправляет мне по почте в случае, если я произошел совершать что-либо непреднамеренное. (или любой шаблон пакета, используя Google-Reflections).