Конфликты в Subversion при обновлении до старой ревизии. Кажется, проблема в слиянии, которое я сделал несколько дней назад. Должен ли я избежать этого слияния?

Question

Я кодирую одну ветку в Subversion уже несколько дней. Сегодня я решил обновить старую ревизию до 30 ревизий назад.

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

Итак, если предположить, что проблема была с merge -r, у меня есть 2 вопроса:

1. Я выполнил слияние -r, чтобы вернуться к старой ревизии, а затем зафиксировать ее, чтобы я мог начать работу с этого момента (я в основном хотел отказаться от своих последних коммитов X на время). Делал ли это -r объединить правильный подход? Должен ли я просто создать другую ветку вместо? Это, конечно, то, что я сделал бы с логическими ветками git, так как это было бы намного чище, но опять же, я не хочу «затоплять» это репозитарий Subversion моими ветками. Может быть, я мог бы просто создать ветку со старой ревизией и удалить эту?

2. Допустим, я сейчас исправлю конфликты. Моя первоначальная идея при возвращении к этой ревизии состояла в том, чтобы выполнить слияние -r (снова). Так что, если через неделю я решу, что хочу вернуться снова, у меня снова будут конфликты, верно? Как избежать этого цикла?

Этот вопрос, возможно, может быть сформулирован по-другому. При кодировании «проб и ошибок» (под этим я подразумеваю, что мне придется «возвращаться» много раз), как мне организовать репо в Subversion?

Спасибо

Answer 1

Помните, что обратное слияние svn не является «откатом и отменой» ваших ревизий, оно отменяет изменения, внесенные в эти файлы в рабочую копию, до тех пор, пока файл не будет выглядеть как требуемая ревизия. Я никогда не слышал, чтобы это приводило к конфликтам (разве у вас нет локальной модификации в вашем WC, которая еще не была зафиксирована?)

Вопрос может состоять в том, чтобы увидеть, что это за конфликт, и посмотреть, сможете ли вы сказать, где и почему он возник.

Использование merge -r является допустимым способом отката к предыдущей ревизии, но создание новой ветки так же верно - это зависит только от того, как вы организовали свое репо и сколько у вас есть веток. Если вы удаляете 30 ревизий, то, возможно, будет немного чище создать новую ветку и удалить старую.

Если вы делаете много попыток + кодирование ошибок, DVCS может быть лучшим вариантом для вас - git позволяет вам регистрироваться локально столько раз, сколько вам нужно, и отправлять только 1 набор изменений в восходящем направлении, отбрасывая все ваши «пробные» проверки (фактически сворачивая их в одно изменение), но, как я уже сказал, у нас никогда не было проблемы с откатом, даже с двоичными файлами, поэтому посмотрите, что это за конфликт.

Answer 2

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