Мы должны быть в состоянии одновременно поддерживать набор различных версий нашей системы. Я предполагаю, что это лучше всего сделать с помощью ветвления. В настоящее время мы используем TFS2008 для контроля версий, рабочих элементов и автоматических сборок.
Какое решение для контроля версий является лучшим для этой задачи? Наша организация находится в процессе слияния с TFS2010. Даст ли нам TFS2010 функциональность, которая нам необходима для простого управления серией веток для каждой версии системы? Мы должны быть в состоянии сохранить каждую версию изолированной от других, чтобы мы могли проводить тестирование и развертывание для каждой версии.
Наша команда разработчиков состоит из 5 разработчиков .net и двух разработчиков flash.
Я слышал много разговоров о GIT. Должны ли мы рассмотреть возможность использования GIT вместо TFS для контроля версий? Можно ли использовать TFS2010 вместе с GIT? У кого-нибудь есть подобные установки, которые хорошо работают?
Любые предложения приветствуются!
Спасибо,
Кжетил.
Основная причина, по которой вам следует рассмотреть Git (или Mercurial):
Если ваша команда находится на одном сайте, и если ваш процесс разработки достаточно линейен (простой рабочий процесс слияния), централизованной VCS будет достаточно.
С этого момента TFS2010 претерпела некоторые интересные изменения, особенно в своей модели ветвления и других встроенных в нее функциях (иерархия рабочих элементов, построение с «закрытой регистрацией» и основанная на «Workflow Foundation») делает его лучшим кандидатом, чем инструмент, ограниченный аспектом VCS.
Subversion !!!
Мне нравится Subversion, + TortiseSVN + VisualSVN
http://subversion.tigris.org/
http: //tortoisesvn.tigris.org /
http://www.visualsvn.com/
Subversion и Tortise бесплатны !, а VisualSVN стоит всего 50 долларов за лицензию (но вам НЕ ОБЯЗАТЕЛЬНО использовать Visual-SVN, это просто интеграция с VS .... Насколько я понимаю, в этом нет необходимости.)
Вот учебное пособие и руководство по установке для всех трех продуктов.
http://www.west-wind.com/presentations/subversion/
Mercurial также справится с этой задачей.
Вот отличный учебник по нему.
Сегодня существует в основном два типа систем контроля версий (VCS), так называемые распределенные VCS и системы центрального репозитория.
Самыми популярными «распределенными» VCS сегодня являются git и mercurial. Самыми популярными системами центрального репозитория являются Subversion и SourceSafe от Microsoft. Введение http://hginit.com объясняет превосходство «распределенной» VCS над центральной системой.
С распределенной VCS каждый разработчик имеет свой собственный локальный репозиторий. Обычно он используется с общим центральным репозиторием, содержащим официальный выпуск. Но это всего лишь репозиторий. «распределенные» VCS превосходят чисто централизованные VCS по способности управлять слиянием.
Все необходимые требования включены в TFS 2010. Ветвление и сохранение ветвей изолированными.
TFS - это не только система контроля версий. Она также является системой контроля работы/отладки и имеет инструменты для интегрированной сборки. Если вам это нужно, и у вас уже есть лицензия на TFS 2010, не тратьте свое время на другие системы.
ОК, TFS не распространяется, но на самом деле, когда я работаю, мне нравится, что TFS не распространяется. Как только я регистрирую материал (в моей личной ветке), он попадает в ежедневную резервную копию и доступен для просмотра другим. (Для своих домашних/хобби/личных вещей я использую mercurial).
Для всех других систем есть инструменты, которые обеспечивают сборку и отслеживание ошибок, так что для других инструментов не проблема, что они недоступны, просто нужно время, чтобы выбрать те, которые соответствуют вашим потребностям.
Мне просто нравится git, и он также интегрируется во многие другие приложения, например Затмение, Trac. кому нужно платить за VCS, когда у вас есть Git.
Тот факт, что при разработке ядра Linux используется git, я знаю, потому что Линус так сказал :), и это немалый проект, говорит сам за себя.
TFS 2010 - безнадежно. Не из-за того, что это отличная система управления версиями, а из-за всего остального, что она делает. GIT оставит вам возможность выбрать отслеживание рабочих элементов, снова непрерывную интеграцию. Сохранение количества поставщиков (низкий уровень технологий является ключевым фактором для лучшего администрирования.
Хорошая система контроля версий поможет мне, когда я работаю разрозненно. Не потому, что мне нравится быть разбросанным, а потому, что повседневные потребности могут разбросать то, как человек работает. Рассеивание усугубляется, когда группа работает параллельно над приличного размера проект.
Человек A работает над функцией 1. Человек B работает над функцией 2. Человек C работает над исправлением обнаруженных ошибок в выпущенной версии.
Пока A выполняет свою работу, он замечает ошибку в коде и исправляет ее на месте, чтобы не пропустить ее, и продолжает. Человек C вносит 3 исправления.
A, B и C общаются в чате, и B чувствует, что ему нужны исправления ошибок, которые сделал C прямо сейчас, а также исправления, которые сделал A, но не его функция. C хочет исправить ошибку A. A хочет исправить ошибку C. И так далее.
Босс решает, что нам нужна версия с функцией 1, другая версия с функцией 2, и версия с обеими функциями, а также версия без выпущенных и поддерживаемых.
Насколько хорошо инструмент поддерживает вас в этих действиях? Насколько инструмент мешает вам в этих действиях?
Я действительно доволен «дарксами».
Я перепробовал много систем контроля версий. Я не встречал ничего лучше.
Это просто, это строго правильно.
Поскольку он строг, он надежен и предсказуем. Поскольку это просто, оно полезно и не мешает вам.
Моим вторым выбором был бы git.
Git неплохой, но не такой строгий, он заставляет вас устанавливать порядок в некоторых случаях, когда порядок не имеет значения. Git более известен, поэтому лучший пункт для резюме.
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
Исходя из моего опыта, если вы ищете DVCS, Git или Mercurial (Hg) - это то, что вам нужно. Однако выбор между Git и Hg - более сложная задача.
Вы в основном используете Windows? Если это так, то, вероятно, ваш друг - Hg. В сочетании с TortoiseHg это очень хороший универсальный инструмент, который легко начать использовать по сравнению с Git. Он немного менее сложен, но справляется с большинством вещей, с которыми может справиться Git, даже если не так гладко.
Если вы используете Linux или оболочку Unix, я бы выбрал Git. Я лично использую Git в Windows, используя утилиту оболочки git. (он также отлично работает в Cygwin, если хотите). Я обнаружил, что Git обрабатывает мои проекты намного эффективнее, чем Mercurial. Однако, если вы не разбираетесь в командной строке, я обнаружил, что TortoiseGit немного сложнее (и неуклюже), чем TortoiseHg. Но поскольку я знаком с bash, я определенно предпочитаю git. Он просто быстрее, компактнее и универсальнее, чем Hg, когда я работал с ними обоими. Это просто немного сложнее, поэтому кривая обучения выше, и на раннем этапе вы можете быть предрасположены к ошибкам с ним, как и я в течение короткого времени.
Итак, по моей оценке, настоящие вопросы таковы:
Windows (Hg) или Unix (Git)
и
Графический (TortoiseHg) или командная строка (оболочка Git)
{{1 }}