Как избежать сложных слияний в Subversion?

Question

Я новичок в Subversion (SVN), работающем в среде Visual Source Safe (VSS). В VSS человек, редактирующий файл, извлекает файл и блокирует других пользователей от редактирования через Visual Studio. Я понимаю, что SVN - это параллельная модель, позволяющая нескольким людям работать над одним файлом, а затем объединять изменения вместе. У меня вопрос такой:

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

2. Есть ли способ уведомить пользователя при получении файла о том, что он в данный момент редактируется другим пользователем или в данный момент заблокирован другим пользователем?

Другие детали:

Использование сервера VisualSVN в качестве сервера SVN.
Использование клиентов TortoiseSVN и AnkhSVN.

Answer 1

Я также бывший пользователь Visual Source Safe. Слияния сводили меня с ума, пока я не понял, что это не проблема технологии, а проблема людей. При использовании VSS большинство разработчиков стараются выполнить как можно больше работы, прежде чем проверять код. Именно такое поведение способствовало сложным слияниям.

Вот несколько вещей, чтобы смягчить это:

• Всегда обновляйте свою рабочую копию перед запуском
• Прибытие часто. Это уменьшит изменения кода, что облегчит автоматическое объединение
• Не оставлять рабочий код непроверенным
• Разработчики должны создать собственную ветку, если изменения займут несколько дней или дольше

Эти вещи очень помогли, тем более что команды, в которых я работал, становились все больше и больше. Репликация поведения блокировки из VSS - очень плохая идея, и она вызовет больше проблем. Просто примите новый рабочий процесс.

Если вы все еще хотите использовать инструмент, тогда я предлагаю вам взглянуть на SVNMonitor .

Answer 2

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

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

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

Answer 3

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

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

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

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

Answer 4

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

Answer 5

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

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

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

Answer 6

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

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

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

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

Answer 7

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

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

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

Answer 8

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

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

Answer 9

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

Вот бросок на 10 * .

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

Answer 10

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

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

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

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

Мы используем TeamCity , который мы считаем превосходным, но есть и другие.