Блог

Я кодировал в одной ветке в Subversion в течение нескольких дней. Сегодня я решил обновить до старой версии, похороненной около 30 ревизий назад.

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

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

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

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

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

Спасибо

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

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

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

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

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