Сценарий для оценки инструментов контроля версий / версий

Question

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

Терминология и внутренняя логика сильно различаются между некоторыми инструментами, было бы неплохо, чтобы сценарий был выражен в терминах вариантов использования ( "Мы должны исправить ошибку в Выпуске 1.3" ), а не в потенциально относящиеся к инструменту термины ( "Создать ветку с именем Release 1.3" ).

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

Кто-нибудь знает что-то подобное? Использовали ли вы аналогичный подход при исследовании средств контроля версий?

Answer 1

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

Если вы найдете сценарии, характерные для вашей компании, возможно, вы сможете перевести их на требования, подобные приведенным выше.

Answer 2

У вас есть некоторые общие критерии с анализом Google DVCS , который может дать некоторые идеи.

Но сначала нужно посмотреть, хотите ли вы оценить:

• CVCS (централизованное управление версиями): update-merge-commit
• DVCS (управление распределенной версией): commit-rebase / merge

Подробнее о тестируемом сценарии (один ответ для CVCS, один для DVCS) см. Вопрос SO:

" Опишите ваш рабочий процесс использования контроля версий (VCS или DVCS) "

Answer 3

Вы должны подвергнуть сомнению такие вещи, как: у вас есть только одна строка Release / Development или мы создаем несколько выпусков параллельно? Вам нужен не только упомянутый сценарий, но вам нужно подумать о том, как объединить изменения в строку dev или несколько других строк. Это может повлиять на подход. Подход, который вы выбрали, звучит очень хорошо, потому что вы пытаетесь понять процесс, а не используя инструментальные термины. Я делал это несколько раз для моих клиентов. В разных командах / компаниях разные вещи обрабатываются по-разному. Поэтому проблема в том, чтобы выяснить, каков ваш процесс (иногда люди не знают об этом).