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

• А: Действительно Использует
• B: Делает не Использование

Сценарий 1: проект требуют, завершают и развернул

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

Не много различия, в большом Сценарии 2 изображения

: После того, как проект выпущен, клиент решает, что они не хотят функцию X

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

Снова, не много различия.

Сценарий 3: Две недели спустя клиент решает, что они на самом деле хотят функцию X

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

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

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

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

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

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

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

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

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

легко видеть, кто фиксировал что, когда, и почему.

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

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

Имеют в виду TFS как ответ на вопрос 'о Microsoft Tools'.

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

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

Избегать вещей как

     "Hey! What happens ? It worked yesterday."

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

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

Главной причиной мы используем управление версиями, является consistentency.

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

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

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

Поскольку:

1. Это уменьшит затраты - Разработчики должны будут провести меньше времени, проверяя объект в реальный VCS, чем их текущий специальный подход.

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

3. Это обеспечит более быстрые, более надежные и простые механизмы резервного копирования - все VCSs создали в дампе возможностей. Они имеют тенденцию быть более сформировавшимися, чем простая копия файла.

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

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

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

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

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

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

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

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

Управление исходным кодом похоже на страховку! Вы надеетесь, что никогда не нуждаетесь в нем, но рады, что у Вас есть он, когда Вы делаете!

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

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

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

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

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

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

Затем делают тот же сценарий с помощью управления исходным кодом.

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

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

, Подверсия свободна и лучше, чем VSS, но VSS затем ничто не определенно лучше.

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

1. Управление исходным кодом дает Вам превосходную историю. Вы видите, где, какие изменения были внесены, таким образом обеспечив отличный способ видеть то, что изменяется со временем (еще лучше, если Вы заполняете отправлять сводку каждый раз)
2. разработчику, она обеспечивает превосходную нейтрализацию, если что-то идет ужасно неправильно. Можно вернуться изменения в файле назад к любой точке в ее истории, таким образом, можно испытать ту модификацию, Вы хотели сделать, и если это не работает, прокручивает его назад легко.
3. Это обеспечивает центральный репозиторий, которого намного легче создать резервную копию, чем обтекание к компьютерам различных разработчиков.
4. Это позволяет Вам переходить проект прочь в другом направлении - полезный для специализаций и настроек.
5. Это позволяет больше чем одному разработчику сотрудничать на том же проекте и том же источнике, позволяя Вам объединиться и иначе управлять изменениями в одной центральной копии.

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

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

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

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

Ответвления

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

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

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

Корректировочная версия

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

Новая возможность

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

Метки/Маркировка

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

Необходимо использовать Управление исходным кодом по этим причинам

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

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

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

4), можно отследить изменения

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

6), Управление исходным кодом является основанием непрерывной интеграции и помогает в широком масштабе с TDD

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

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

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

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

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

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

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

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

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

Так, слабые места Вашей существующей системы:

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

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

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

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

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

Вы всегда, всегда хотите иметь своего рода Управление исходным кодом, даже если Вы работаете над проектом собой.

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

Не наличие своего рода управления исходным кодом является чистым безумием.

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

, Если Ваш босс полон решимости придерживаться инструментов Microsoft, пойдите для Сервера Основы Команды вместо VSS. Это - намного лучшая система, чем VSS, и это имеет хорошие функции как интегрированное отслеживание ошибок.

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

Вот простой реальный пример.

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

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

, Но у нас есть управление исходным кодом! Таким образом, я делаю это:

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

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

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

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