Ответ 1

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

• A: Использует ли
• B: не использует

Сценарий 1. Проект запрашивается, завершается и выполняется

A + B) Программисты разрабатывают проект самостоятельно, когда он завершается, выталкивают его на тестирование, а затем доставляют клиенту (кто бы это ни было)

Не большая разница, в большой картине

Сценарий 2. После выхода проекта клиент решает, что им не нужна функция X

A + B) Разработчики удаляют код, который клиент не хочет, тестирует и доставляет.

Опять же, не большая разница.

Сценарий 3. Через две недели клиент решает, что на самом деле им нужна функция X

A) Разработчики реинтегрируют код, который они извлекли в 2, в нормальное дерево разработки, проверяют и доставляют.

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

Легко получить старый код, который вы извлекли по той или иной причине

Сценарий 4. В системе возникает странная ошибка, когда функция должна возвращать логический результат, но всегда возвращает false. Это было не так, как две недели назад.

A) Разработчики изучают все старые версии программного обеспечения и выясняют, что директива return false не входит в правильную область действия - она ​​выполняется внутри цикла вместо внешнего.

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

Сценарий 5: Кто-то нарушает сборку. Он проходит тестирование и замечен только через несколько недель.

A) Команда исследует историю фиксации, узнает, кто нарушил сборку, заставляет этого человека исправить ее и купить ужин команды.

B) Команда должна вернуться через весь проект, чтобы найти ошибку, но не может понять, кто ввел этот код. Разработчики винят друг друга, а динамика команды терпит неудачу.

Легко понять, кто что сделал, когда и почему.

Ответ 2

Используйте источник управления, потому что ни вы, ни ваша команда не идеальны. Основная функция управления версиями состоит в том, чтобы гарантировать, что у вас есть полная историческая запись вашего процесса разработки. Имея эту запись, вы можете уверенно разветвляться с "экспериментальными" версиями, зная, что если эксперимент не удастся, вы можете выполнить резервное копирование до более ранней версии.

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

Ответ 3

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

Ответ 4

Для этих целей вам необходимо использовать Source Control.

1) Вы можете откат к любой версии

2) Различные разработчики могут работать с одними и теми же файлами

3) Все разработчики будут иметь доступ к одной и той же базе кода

4) Вы можете отслеживать изменения

5) Вы можете отменить изменения, которые не работают

6) Исходное управление является основой непрерывной интеграции и помогает в значительной степени с TDD

7) Если вы не используете элемент управления источником, вы будете постепенно сходить с ума, поскольку файлы будут потеряны/перезаписаны, и ничто не будет работать так, как должно быть

VSS - не худшее приложение SCC, я использовал его в течение многих лет и стал ненавидеть его, но он работает, прост, и многие знают об этом.

Ответ 5

Microsoft (MSDN) имеет хорошую статью о преимуществах контроля источника.
http://msdn.microsoft.com/en-us/library/ms173539.aspx

Здесь также есть много хороших вопросов, касающихся плюсов и минусов.
Каковы ваши плюсы и минусы git после его использования?

Subversion очень популярен, но git станет "следующей большой вещью" в мире управления версиями.

Ответ 6

Вот простой пример в реальной жизни.

Несколько лет назад мой босс сказал: "Функция XYZ работала, а теперь это не так. Никто не знает, что произошло. Можете ли вы это исправить?"

Теперь я никогда раньше не работал с функцией XYZ. Поэтому исправление этого будет связано с большим количеством попыток выяснить, что он делает.

Но у нас есть контроль источника! Поэтому я делаю это:

• Создайте тест script для проверки функции XYZ: "Нажмите здесь, введите это, нажмите там и т.д."
• Получить текущую версию. Построить. Контрольная работа. Функция XYZ сломана.
• Получить версию с недели назад. Построить. Контрольная работа. Функция XYZ работает.
• Получить версию на полпути между этими двумя. Построить. Контрольная работа. Функция XYZ работает.
• Получить версию на полпути между предыдущей и текущей. Построить. Контрольная работа. Функция XYZ сломана.

Я продолжал делать этот бинарный поиск, пока в конце концов не попал в точку изменения: в версии 145 (мы скажем) работала функция, но версия 146 сломалась. Затем я просто сравнил эти две версии, чтобы увидеть, что изменилось. Оказывается, наш технический лидер (вздох) проверял код, который менял функциональность, но также ввел побочный эффект, который нарушил функцию XYZ.

Итак, я удалил побочный эффект, протестировал... и вот, функция XYZ снова работала.

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

С помощью элемента управления вы просто проверяете свой путь через версии, точно определяете то, что вызвало эту проблему, и исправляйте ее.

Ответ 7

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

Филиалы

Без репозитория исходного кода невозможно создать ветки (или копии/поток/etc.) вашего кода для определенных целей. Невозможность создания и объединения веток - одна из самых больших вещей, которые дисквалифицируют VSS от реальной системы управления исходным кодом. Некоторые из целей ветки включают в себя:

Исправление ошибок

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

Отпуск обслуживания

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

Новая функция

Иногда вам нужно приступить к разработке новой версии при сохранении вашего текущего кода. Например, вы выпускаете и поддерживаете v1.0, но вам нужно начать работу над версией v2.0 при сохранении версии 1.0. Отрасли помогают разрешить эту ситуацию.

Пометка/Этикетировочное

Другая система управления исходными кодами - это сделать снимки исходного кода в определенный момент времени. Они называются ярлыками в VSS, тегами в подрывной деятельности и т.д. Создавая их на регулярной основе и связывая их с какой-то значительной вехой в вашем проекте, становится возможным определить, что именно изменилось в вашем коде между выпусками. Это может быть важно для аудиторов, а также для отслеживания источника/объема проблемы. VSS также получает отказ здесь, потому что VSS поддерживает только файлы, а не каталоги. Это означает, что невозможно пересоздать предыдущую версию системы, если вы переименовываете/перемещаете/удаляете файлы или каталоги в репозитории (что-то очень часто происходит, если вы рефакторинг). Хорошие системы управления исходным кодом, такие как Subversion, делают именно это.

Ответ 8

Я предлагаю использовать SVN, потому что:

• Исходный контроль дает отличную историю. Вы можете видеть, какие изменения были внесены, что дает отличный способ увидеть, что изменилось с течением времени (даже лучше, если вы каждый раз заполняете резюме резюме)
• Разработчику, он обеспечивает отличный отступ, если что-то идет ужасно неправильно. Вы можете вернуть изменения в файл обратно в любую точку своей истории, чтобы вы могли попробовать этот мод, который хотите сделать, и если он не работает, легко сканируйте его обратно.
• Он предоставляет центральный репозиторий, который намного легче выполнять резервное копирование, чем работать с компьютерами разных разработчиков.
• Это позволяет отделить проект в другом направлении - полезно для специализаций и настроек.
• Это позволяет нескольким разработчикам работать вместе над одним и тем же проектом и одним и тем же источником, позволяя объединить и иным образом манипулировать изменениями в одной центральной копии.

Я предлагаю НЕ использовать VSS - см. эту страницу по причинам: http://www.highprogrammer.com/alan/windev/sourcesafe.html по нескольким причинам.

Ответ 9

Наличие некоторой системы контроля версий помогает в любом, много случаях:

Одиночный разработчик, единственная ветвь

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

  Системы управления версиями занимают гораздо меньше места на диске по сравнению с простое сохранение резервных копий с указанной датой, поскольку они используют дельтаизацию (сохраняя только отличия от предыдущей версии) и сжатия. Обычно системы резервного копирования - это средства для хранения последних N версий проекта, иногда с N = 1 (только предыдущая версия), в то время как системы управления версиями (VCS) хранят всю историю проекта. Зная Murphy через некоторое время после удаления N-й последней версии, вы поймете, что это была версия, которую вы хотите изучить.

  Кроме того, возврат к некоторой последней версии легко и автоматизирован. Вы также можете проверить, как один файл выглядел как в прошлой версии, и вы можете получить различия (в формате diff) между текущим состоянием и некоторой прошлой версией. Вы также можете использовать тег (или 'label'), чтобы вы могли ссылаться на прошлую версию не только по дате, либо на версию n th от текущей, но также по символическому имени, например v1.2 или v1.2-rc0.

• С системой контроля версий вы можете изучить историю, чтобы напомнить вам, почему (и как) какой-то фрагмент кода (какая-то часть данного файла) прибыл в текущее состояние. Большинство VCS позволяют рассматривать линейную историю файла, т.е. Аннотировать каждую строку файла, когда он был изменен, в какой фиксации и кем (команда называется annotate, blame или praise в зависимости от VCS). В некоторых VCS вы можете искать историю для версии (ревизии), которая вводила данный фрагмент кода (например, называемый "поиск кирки" в Git, один из VCS).

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

  Эта функция, конечно, еще более полезна, если вы не единственный разработчик...

• Использование системы контроля версий позволяет альтернативно искать ошибки в коде, а именно путем поиска истории, чтобы найти версию, в которой была введена ошибка: история bisectiong. Когда вы найдете ревизию, в которой была введена ошибка, у вас была бы ограниченная (в лучшем случае: очень ограниченная) область для поиска ошибки, потому что ошибка должна быть в разнице между последней рабочей версией и первой версией с ошибкой. Также у вас будет описание изменения (сообщение фиксации), чтобы напомнить вам, что вы хотели сделать. Эта функция также иногда называется diff отладки. Современные системы управления версиями (VCS) поддерживают автоматизированный (или полуавтоматизированный) поиск истории путем деления его пополам (разделение истории пополам, определение того, какая часть содержит ошибку, повторение до тех пор, пока не будет найдена одна ответственная версия) в форме bisect (или аналогичной) команды.

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

• Большинство систем управления версиями предлагают различные крючки, которые позволяют, например, автоматическое тестирование или автоматическое построение продукта... или просто напоминают вам, что вы не следуете стандарту кодирования (кодирование руководящие принципы).

Один разработчик, несколько ветвей

• Системы управления версиями позволяют создавать несколько альтернативных параллельных линий разработки, называемых ветвями (или потоками или представлениями). Общий случай имеет ветки развития, т.е. Имеет отдельную ветвь для нестабильной разработки (для тестирования новых функций), отдельную ветку для стабильной (основной, магистральной) версии, которая (или должна быть) текущей рабочей версией, и один на несколько отдельных отделений обслуживания (фиксации).

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

• Современный VCS (здесь современный означает, что как ветвящиеся, так и сплит-ветки легко) позволяют идти немного дальше, т.е. генерировать отдельную ветку для работы над отдельной функцией (так называемые ветки темы). Это позволяет вам переключиться между одной рабочей функцией и работать с другой функцией (и не только переключиться с разработки новой функции на работу с исправлением исправления).

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

Несколько разработчиков

• Использование систем управления версиями приносит еще больше преимуществ, если в одном проекте работает более одного разработчика. VCS допускает совместную (параллельную) разработку, не беспокоясь о том, что кто-то перезапишет ваши изменения или не учтет ваши изменения. Конечно, использование системы контроля версий не заменяет связь.

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

Ответ 10

Простой: если код не находится в безопасном источнике, он не существует

Subversion свободен и лучше, чем VSS, но VSS определенно лучше, чем ничего.

Ответ 11

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

Как только вы знаете, почему, легко найти сценарии, в которых может помочь управление версиями.

Ответ 12

Долгое обсуждение того, почему вы должны абсолютно контролировать исходный код:

Требуется ли управление версиями для небольшой группы разработчиков (1-2 программиста)?

Мои комментарии из этого потока:

Ты всегда, всегда хочешь иметь вроде управления версиями, даже если вы работая над проектом самостоятельно.

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

Отсутствие какого-либо контроля источника это чистое безумие.

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

Если ваш босс решил придерживаться инструментов Microsoft, перейдите на Team Foundation Server вместо VSS. Это намного лучшая система, чем VSS, и она имеет приятные функции, такие как встроенное отслеживание ошибок.

Ответ 13

Если текущий процесс копирует папку и дает ей дату, разве это не так, что вы получаете какую-то историю развития, так что это не простая форма управления версиями?

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

То, что вы сейчас делаете, очень хрупок и упадет, если возникнет какой-то сложный сценарий, и вам придется потратить много энергии на то, как сделать то, что уже делают инструменты. VSS лучше, чем то, что вы делаете, но не имеет очень полезных соглашений, которые SVN, git или mercurial имеет, что позволяет нескольким проектам жить вместе хорошо организованным образом - я говорю о ветвях, тегах и слиянии, оба из которых хрупкие и в основном кошмар под vss.

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

Итак, слабые стороны вашей текущей системы:

• Если вам нужно внести изменения в файл, вы, скорее всего, перезапишете или перезапишете изменения других разработчиков. Вы можете даже не заметить этого.
• Если вам нужно запомнить, какие файлы вы изменили, чтобы скопировать их по какой-либо "основной" копии, вы, вероятно, в какой-то момент пропустите ее.
• Удачи, когда-либо находил какую-либо документацию о том, когда вы внесли изменения и почему.
• Как вы могли бы построить стабильную автоматическую систему сборки в своей текущей системе? Круиз-контроль и hudson работают очень хорошо, вы ковыряете себя.
• VSS не очень хорошо группирует изменения в несколько файлов. Все современное делает это очень хорошо и с атомной согласованностью.
• Поддержка VSS и поддержка слияния ужасная. Когда мы его использовали, мы заключили брекетинг каждого изменения с комментариями в исходном коде и копированием кода вручную, а не слиянием с VSS.
• В вашей нынешней системе будет очень сложно, почти невозможно, иметь версию кода в режиме реального времени и другую, более позднюю версию, в тяжелом развитии. Подумайте о том, что нужно, чтобы синхронизировать два проекта таким образом, вам нужен хороший инструмент. SVN может это сделать, git может сделать это очень хорошо.

Этого может быть достаточно, чтобы продолжить, можно сделать больше.

Ответ 14

Возьмите его у меня, VSS ударит. Это основное хранилище файлов с историей. Все лучше, чем VSS и VSS лучше, чем ничего:)

Ответ 15

Почему формальная презентация?

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

Затем выполните тот же сценарий, используя элемент управления source.

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

Ответ 16

Придерживайтесь нижней строки, объясните, как она относится к деньгам, и ваш босс, вероятно, будет слушать.

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

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

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

Ответ 17

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

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

На работе мы используем subversion, но некоторые разработчики (включая меня) используют Git локально через мост git -svn. Для личной работы я использую Git.

Ответ 18

Итак, можете ли вы, ребята, сказать мне, почему разработчики ДОЛЖНЫ использовать контроль источника?

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

Source Control - это как страховка! Вы надеетесь, что вам это не понадобится, но радуйтесь, когда вы это делаете!

Ответ 19

Почему ваша команда не должна принимать контроль над версиями?

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

Ответ 20

Основная причина, по которой мы используем контроль версий, - это согласованность.

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

Ответ 21

Удостоверьтесь, что у вас есть покупка для остальной части команды. Может быть, вы можете проверить свою презентацию на них? Надеюсь, они тоже понадобятся.

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

Ответ 22

Потому что:

• Это снизит затраты. Разработчикам придется тратить меньше времени на проверку элемента в/из реального VCS, чем на их текущий ad-hoc-подход.

• Это защитит интеллектуальную собственность организации - это должно быть самым важным соображением для любой компании-разработчика программного обеспечения (кроме данных...). Вам платят за создание программного обеспечения - не должно ли оно быть доступно полностью?

• Он будет обеспечивать более быстрые, надежные и простые механизмы резервного копирования - все VCS имеют встроенные возможности демпинга. Они, как правило, более зрелые, чем простая копия файла.

• Он будет действовать как механизм связи между разработчиками - в зависимости от системы контроля версий вы можете использовать комментарии/метки/статус проверки, чтобы определить, работал ли кто-то другой в файле, если он был продвинут на производство, если у него есть соответствующий номер билета поддержки и т.д.

• Он упрощает разработку - возможность сравнивать версии файлов, а также другие механизмы будут полезны для периода вашей компании.

Ответ 23

Самый простой способ убедить руководство инвестировать Время в SCCS сосредоточено на резервном копировании и архивировании. Используя что-то вроде Subversion (SVN), вы можете мгновенно восстановить любой проект в любой момент времени. Нет необходимости, чтобы кто-то просматривал резервные ленты или беспокоился о отслеживании нескольких версий в тупой структуре каталогов.

Очевидно, есть много других преимуществ (т.е. 2 человека, работающих в одном файле одновременно), но резервные копии - это то, что быстро продало мою компанию много лет назад.

Ответ 24

Чтобы избежать таких вещей, как

     "Hey! What happens ? It worked yesterday."

Ответ 25

Другие упоминали о конкретных преимуществах управления источниками в других местах, но я хотел явно обратиться к части "VSS" вопроса.

Если ваш босс хочет использовать инструмент Microsoft, Team Foundation Server с Team Suite - очень приятная комбинация. Он также включает в себя другие инструменты, такие как отслеживание ошибок, документы и возможности отчетов, что делает хорошую платформу для дальнейшего улучшения вашего процесса. Мы очень довольны тем, где я работаю, и мои коллеги рассказали мне ужасные истории о VSS.

Учитывайте TFS как ответ на вопрос "Инструменты Microsoft".