Как убедить мою команду отказаться от sourceafe и перейти на SVN?

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

Какие аргументы вы нашли наиболее полезными, чтобы убедить вашу команду перейти к лучшему решению, например SVN?

Какие программы вы использовали для устранения разрыва в функциональности, чтобы команда не упустила интеграцию ide sourcesafe?

Или я должен просто принять sourcesafe и попытаться переделать в него лучшие практики?

Ответ 1

Во-первых, научите их эффективному использованию SourceSafe.

Если они достаточно умны, они будут любить преимущества использования системы контроля версий, и если это так, они скоро достигнут пределов SourceSafe. Что там, где они будут более способны слушать ваши аргументы для перехода на лучший VCS, может ли это быть CVCS или DVCS, в зависимости от того, что команда готова к достижению.

Если вы попытаетесь заставить их использовать другой VCS, если они неправильно используют SourceSafe, например, сохранить zip файл исходного кода (не смейтесь, как они действовали в моей компании два года назад), они будут быть полностью неохотой к какой-либо аргументации, насколько это возможно.

Ответ 2

Надежность

  • SVN намного надежнее с большими базами данных
  • SVN по-прежнему активно поддерживается
  • Атомная фиксация - в VSS, когда вы получаете последнюю версию, в то время как другой пользователь выполняет checkin, вы можете получить несогласованное состояние, заставляя вас повторять "Получить последнюю версию" в лучшем случае, но иногда, когда вам не повезло, код, который компилируется, но не работает. Это не может произойти в SVN благодаря атомным коммитам.

Функции

  • SVN-ветвь/слияние намного лучше
  • SVN имеет встроенную поддержку удаленного доступа.
  • SVN более настраивается (интеграция внешних инструментов Diff/Merge)
  • SVN более расширяемый (крючки)

Повышение производительности

  • SVN "Обновление" быстрее по сравнению с SS. Получите последнюю версию.
  • Командная строка SVN намного проще и чище - это полезно для автоматизированных средств сборки или тестирования.

Тот же уровень интеграции IDE

  • У VSS была намного лучшая интеграция VS до недавнего времени, но с AnkhSVN 2.0 это уже не так.

Открыть

SVN открыт и существует множество различных инструментов, использующих SVN или взаимодействующих с ним. Вот некоторые примеры:

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

Стоимость

  • Вам не нужно платить за лицензию или плату за обслуживание.

Ответ 3

Найдите некоторый повод для начать использовать символы, отличные от ASCII, в вашем коде С# (для этого подходят китайцы и японцы).

SourceSafe не любит Unicode (даже если Visual Studio делает это), поэтому, если вы выберете правильный текст в Юникоде и проверьте файл и отпустите его, весь ваш файл появится в виде поврежденной тарабарщины. Красота заключается в том, что, поскольку SS использует систему контроля версий "diff", это фактически полностью искажает файл до исходной версии проверки и не может быть исправлено автоматически.

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

Ответ 4

Были две функции, которые мы использовали для управления продажами и командой SVN над VSS.

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

2) Возможность откат всего изменения сразу. Поскольку SVN записывает все файлы, измененные в одном атомарном коммите, тривиально возвращать проблематичное изменение. В VSS разработчик должен был пройти через весь репозиторий и найти каждый файл, измененный примерно в одно и то же время, и вернуть каждое изменение в каждый файл по отдельности. С SVN это так же тривиально, как найти соответствующую фиксацию и нажать кнопку "Отменить изменения с этой фиксации" в TortoiseSVN.

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

Ответ 5

Что бы вы ни делали, двигайтесь медленно! Не начинайте говорить с ними о ветвлении в День 1 - он просто отложит их. Я стереотипирую пользователей VSS с этим комментарием, но это то, что я вижу там.

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

Для администраторов: продайте их на более стабильном и удобном в управлении, чем VSS. Покажите им сервер VisualSVN.

Удачи!

Ответ 6

Никто не рекомендует использовать SourceSafe больше, даже Microsoft. Теперь они предлагают вам (дорогостоящую) лицензию TFS. SourceSafe просто ненадежен.

Я написал об этом здесь: Visual SourceSafe на E2. Это немного напыщенная речь, но это потому, что мне пришлось долгое время использовать SourceSafe, и память заставляет меня пнуть в рот немного.

Доверенность - это большая, которая вас укусит. Но также есть функции, которые вы можете оценить в SVN или TFS:

TFS и SVN имеют атомарные коммиты из нескольких файлов, но Sourcesafe не делает - если вы дважды проверяете два файла ", это не одна операция, это то же самое, что и проверка в одном из файлов, а затем проверка Другие. Вы можете попасть в состояние между ними, где один файл был зарегистрирован, но не другой.

SourceSafe не сохраняет историю удаленных файлов, перемещает файлы или переименовывает.

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

В отличие от SourceSafe, TFS и SVN работают отлично с серверами в Интернете (TFS просто ОК, SVN отлично), а SVN хорошо работает в автономном режиме - например, если у вас есть ноутбук на самолете или поезде, и нет "сети", вы все равно можете работать и сравнивать с предыдущими версиями или даже возвращаться, так как данные для этого выполняются локально.

Как заметил кто-то другой, SourceSafe, подобно CVS, является "мертвым" продуктом. Он не активно развивается. TFS и SVN будут иметь следующие версии в будущем.

Ответ 7

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

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

Если вы можете выяснить приблизительные затраты времени и денег на проблемы, вызванные использованием источников и преимуществами вещей, которые предоставляет подрывная деятельность (с использованием общего номера, например, 100 долл. США/час на оплату труда или просто часов) и любых расходов на позднюю доставку проектов, Сделай так. Если вы собрали данные в течение месяца или около того, вы можете показать преимущество с помощью подрывной деятельности в месяц.

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

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

Ответ 8

Плагин AnkhSVN для VS довольно хорош. Он получил несколько странностей, но в целом хорошо работает.

Убеждение команды к переезду - это тяжелая работа. Я никогда не справлялся с этим:-( Вероятно, одним из наиболее практических аргументов является скорость - VSS медленный, когда у вас есть исходная база данных 1 ГБ и несколько пользователей.

edit Это было так давно, как я использовал VSS, я забыл, что это была блокировка! Да, как упоминалось здесь, способность перейти к модели неэксклюзивного/слияния изменений должна помочь, если у вас есть больше, чем несколько разработчиков. Это экономит крики "Может ли кто-нибудь проверить общий доступ" через офис?

Ответ 9

Вы говорите: "Какие аргументы вы нашли наиболее полезными, чтобы убедить вашу команду перейти к лучшему решению, например SVN?"

Если вы не знаете, что это лучшее решение, то почему вы делаете аргументы? Если ваш ум достаточно подготовлен, чтобы рассуждать о решении, вы должны знать, что это за причины.

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

Ответ 10

TortoiseSvn (бесплатно) действительно приятно для интеграции с исследователем, предоставляя вам все функции svn из контекстного меню.

VisualSvn (коммерческий) упрощает интеграцию svn в Visual Studio с тем же индикатором статуса в браузере решений а также контекстные меню для использования всех функций subversion.

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

То же самое, что каждый сказал о том, что VSS является poop

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

Ответ 11

Сначала найдите google для количества страниц, описывающих, насколько плохой VSS, и делитесь им с вашими коллегами.

Во-вторых, пропустите subversion и перейдите прямо к надлежащему распределенному SCM, например git или mercurial. Поскольку слияние является неотъемлемой частью распределенных SCM, они должны обрабатывать слияния намного лучше, чем централизованные системы, такие как svn. Subversion все еще пытается модернизировать себя, чтобы лучше обрабатывать ветвление, где распределенные системы были правильно построены.

Ответ 12

Построить некоторую автоматизацию, которая отражает репозиторий VSS в репозитории SVN

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

Ответ 13

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

Лучший аргумент против SourceSafe заключается в том, что он просто не Safe, все остальное можно назвать "функциями, которые нам не нужны".

Ответ 14

Клиентом для нас была скорость (т.е. ее отсутствие) VSS по VPN и сети с низкой пропускной способностью на дороге и проблемы с туннелированием через брандмауэры, чтобы две команды на двух разных сайтах могли быстро, надежно, и надежно работать из одного и того же репозитория кода. Мы использовали два хранилища VSS и упаковывали "поставки", которые нужно было объединить в другой репозиторий сайтов, чтобы синхронизировать их.

Команда ворчала на некоторое время, но быстро преодолела это. TortoiseSVN фантастичен сам по себе, и подключаемый модуль AnkhSVN для Visual Studio действительно облегчил всех в переходе.

Оглядываясь назад, я не могу поверить, сколько "Можете ли вы проверить файл SoAndSo?" которые мы отправили, не говоря уже о том, что "SourceSafe не работает. Мы должны восстановить репозитории".

Sheesh. После прочтения этих комментариев и написания этого ответа я не могу поверить, что мы терпим VSS до тех пор, пока мы это сделали.

Ответ 16

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

Ответ 17

Недостоверность безопасного источника ( "пожалуйста, исправьте репозиторий..." ) была достаточной для продажи для нас. Andecdotally (я никогда не измерял это) SVN также всегда кажется быстрее. Хорошие одновременные проверки/слияние.

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

Ответ 18

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

У меня есть аналогичная проблема с CVS при моем текущем использовании клиентов. Поскольку "он работает", и они в основном довольны этим, я не могу заставить их измениться. Но каждый день я бы хотел, чтобы они!

Ответ 20

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

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

Ответ 21

Раньше мы использовали SourceSafe. Затем, когда я присоединился к команде, я был в другом месте, и хотя у нас довольно хорошая локальная сеть, когда я пытался проверить последнюю версию, это заняло 40 минут. Я убедил их конвертировать в CVS (теперь мы используем SVN), а время проверки сократилось до пары минут. SourceSafe был слишком медленным, чтобы его можно было использовать в удаленном месте.

Ответ 22

Мы перешли из SourceSafe в Source Gear Vault. Этот механизм управления источником очень удобен для некоторых, которые использовались в SourceSafe. Наконец, мы решили внести изменения после нескольких инцидентов с коррупцией SourceSafe, которые произошли в критические моменты. Поэтому мой совет будет сосредоточить вашу презентацию продаж на ненадежности SourceSafes.

Ответ 23

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

Я использовал SVN и CVS на моей старой работе и перешел в компанию, которая использует Source safe (мы собираемся перейти на SVN), и просто использовать VSS было достаточно для меня, чтобы серьезно не понравиться. Я вошел с открытым умом, несмотря на то, что многие мои коллеги из моей предыдущей работы рассказывали мне ужасные истории о VSS. Я предположил, что с тех пор они стали лучше, чем они использовали.

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

Исходный сейф мешает развитию, где SVN помогает вам практически на каждом шагу.

Плюс Использование черепахи Svn сделал обзоры кода намного проще.

Ответ 24

Только до тех пор, пока вы можете стадо кучу кошек. Я был там дважды, и в обоих случаях в Source Safe возникли серьезные проблемы, прежде чем люди увидели свет. В качестве менеджера, с другой стороны, я просто поручил команде использовать SVN, и наша производительность увеличилась на 300% (это работало с группой в Индии и США. У нас были обмен кодов, которые занимали много времени до svn)

Ответ 25

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

Ответ 26

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

Ответ 27

Заставьте их использовать его, и они переключится на что-то еще:)

Теперь, будучи серьезным, скажите им, что это не так сложно использовать, многие разработчики, которых я знаю, отказались переключаться, потому что они связаны с подрывными действиями с командами unix и wierd, показывают им интерфейсы, такие как ToirtoiseSVN или VisualSVN, скажите им, что Subversion позволяет им редактировать один и тот же файл с принудительной блокировкой, такой как VSS.

И последнее, но не менее важное: Open Source. Он имеет более низкую стоимость, чем покупка Team Foundation Server, и если вы посмотрите вокруг, вы увидите, что небольшие команды разработчиков хорошо работают с SVN.

Ответ 28

Я использовал SourceSafe в небольшой команде разработчиков и отвечал за ее работу.

Я обнаружил, что база данных повреждена довольно легко, и при этом не так много прибегают, когда это происходит. Функция "ремонта" (как и в большинстве других функций восстановления Microsoft) просто не работает в 98% случаев.

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

SourceSafe - это просто катастрофа, ожидающая своего успеха.

Ответ 29

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

Однако проблема №1 для меня и всегда была в том, что эта чертова вещь настолько подвержена коррупции - если у вас есть ваша база данных SS (lol, database; коллекция случайно названных файлов более точно описывает ее) на сетевой диск, и что-то происходит с вашим подключением к локальной сети через операцию добавления/проверки - в 9 раз из десяти вы получаете "недействительный дескриптор", и проклятая вещь каким-то образом повреждена, а затем вы можете играть в русскую рулетку с помощью Инструмент анализатора.

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

Итак, все. Я, вероятно, буду использовать Subversion и TortoiseSVN, потому что я думаю, что команде понадобится интерфейс, чтобы облегчить переход.

Ответ 30

В моей предыдущей работе мы начали с VSS, затем переместились в SVN и никогда не оглядывались назад.

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

Невозможно добавить файл в проект, потому что кто-то из файлов проекта проверен, это бесит!

- Ли