Как я избегаю Сложных Слияний в Подверсии?

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

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

По нашему опыту, по большей части люди не работают над одним и тем же файлом или, по крайней мере, с одной и той же частью файла одновременно (в VSS вы не могли , поэтому ваши рабочие шаблоны вероятно, уже поддержали вас в этом).

Еще одна важная вещь - убедитесь, что все используют одни и те же правила для использования табуляции / интервалов, для макета и для форматирования,

Хотя SVN имеет команду lock , наиболее распространенный способ использования SVN включает оптимистичный подход к блокировке.

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

Затем вам нужно будет запустить команду «Обновить», которая (скорее всего) автоматически объединит мои зафиксированные изменения с вашими локальными изменениями, и тогда ваша следующая попытка фиксации будет выполнена.

Чтобы избежать проблем с этим оптимистичным подходом: как предлагали другие, делайте коммиты чаще и не делайте слишком много сразу!

Пара моментов, с которыми я столкнулся в предыдущем месте, когда мы перешли от системы на основе блокировки к SVN.

Это не совсем так. Хорошая идея - попытаться воспроизвести поведение блокировки-редактирования-разблокировки в SVN, поскольку оно было разработано таким образом, что вам не нужно работать таким образом. Алгоритмы слияния, используемые SVN, довольно хороши, и я встречал лишь несколько случаев, когда требовалось ручное вмешательство во время слияния. Это' Удивительно редко, когда два человека, работающие над одним файлом, на самом деле касаются одной и той же строки (строк), и последнее часто является единственным случаем, когда требуется ручное вмешательство.

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

Если вы пытаетесь использовать SVN не как «собственный SVN», а как VSS с другим именем , это будет больно, и хлопот не стоит. Освоитесь с новой парадигмой, и вы '

Нет проблем. Используя Tortoise SVN, сделайте следующее ...

1. В проводнике Windows щелкните правой кнопкой мыши значок файл (ы).
2. Выберите "Tortoise SVN", а затем "Получить Блокировать ... "
3. В диалоговом окне" Блокировать файлы "введите в причине блокировки.
4. Нажмите OK.

SVN - это параллельная модель, позволяющая нескольким людям работать над одним и тем же файлом, а затем объединять изменения вместе.

Я думаю, что это больше о работе над одним и тем же проект , состоящий из группы более или менее независимых файлов. Работа с одним и тем же файлом и объединение результатов, безусловно, возможны и действительно случаются время от времени, но это определенно не режим работы по умолчанию / желаемый. Итак:

• Обновляйте часто.
• Часто фиксируйте.
• Избегайте больших классов / файлов (1000 строк - это слишком много). Это также имеет дополнительные преимущества: -)

Я бы потратил некоторое время на то, чтобы узнать о "чеке в танце"

Вот десять центов на него.

В Интернете также есть множество статей об этом и о том, как облегчить боль.

Краткий ответ:

1. Обновляйте часто. Заезд рано, заезд часто. Если вы работаете над чем-то дольше (более одного или двух дней), подумайте о создании функциональной ветки.
2. Нет.

Несколько более длинный ответ:

Если несколько разработчиков вносят «тонны и тонны изменений» в один и тот же файл, что-то не так с тем, как работают ваши разработчики, или с тем, как функции распределены по разным файлам. Я' Я работал с CVS и SVN в группах разного размера и IME, очень мало случаев, когда слияние становится реальной проблемой. (Обычно это изменения фундаментальных служб, таких как строки, ведение журнала, обработка ошибок и т. Д., Которые требуют изменения практически всего кода. Такие случаи требуют некоторого вмешательства человека и планирования, чтобы все прошло гладко.)

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

Затем, если у вас есть изменения, требующие долгое время по необходимости стоит периодически выполнять svn update , чтобы максимально синхронизироваться с основной линией. Subversion довольно респектабельна при слиянии (по сравнению с VSS) и будет хорошо справляться с большинством вещей.

Все, с чем она не справится, она перейдет в конфликтное состояние, оставляя вам решать конфликты с помощью инструмента слияния вашего выбор (для этого рекомендую WinMerge , это туз).

Я хотел бы предложить другой подход к использованию Subversion.

• Вы должны получать обновления часто.
• Вы также должны проверять рано и часто.

При таком подходе слияние обычно происходит нечасто и происходит автоматически. В случае конфликтов они часто меньше.