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

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

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

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

Надежность

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

Функции

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

Лучшая производительность

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

Одинаковый уровень интеграции IDE

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

Открытым

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

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

Расходы

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

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

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

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

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

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

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

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

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

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

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

Удачи!

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

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

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

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

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

Никто больше не рекомендует использовать 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 выйдут в ближайшее время.

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

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

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

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

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

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

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

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

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

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

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

То же самое с тем, что каждый сказал о том, что VSS какашки

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

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

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

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

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

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

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

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

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

Веб-страница с кратким описанием проблем с VSS - просто укажите людям на этот URL

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

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

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

Скажите им, чтобы они прочитали этот http://www.highprogrammer.com/alan/windev/sourcesafe.html

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

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

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

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

Когда я был при запуске VS2005, мне удалось загнать Microsoft в угол и спросить, почему SourceSafe так ужасно использовать. Ответ, который я получил, был довольно шокирующим не только из-за того, что он сказал, но и потому, что он был так откровенен в отношении того, что он сказал.

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

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

Итак, вскоре после этого мы перешли на подрывную деятельность. Мы практически решили пойти на это до запуска, но это только подтвердило, что мы приняли правильное решение.

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

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

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

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

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

Безопасность исходного кода мешает разработке, где SVN помогает вам практически на каждом этапе.

Плюс Использование черепахового Svn значительно упростило проверку кода.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Ли

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

Джоэл Спольски написал очень хорошее введение в Mercurial, и вы можете использовать также плагин для Visual Studio.

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

Также всякий раз, когда я показывал людям преимущества непрерывной интеграции (в частности, CruiseControl.NET); этого часто бывает достаточно, чтобы оправдать переход от VSS к SVN (я считаю, что SVN работает с CruiseControl.NET намного лучше, чем VSS).

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

Вы будете удивлены, насколько быстро VSS умирает таким образом.

Отличная книга по этой теме - «Как движутся технические изменения».

http://pragprog.com/titles/trevan/driving-technical-change