Потратив все утро, пытаясь что-то проверить - теперь я понимаю, что потерял пару дней работы.
Это произошло раньше - и, по-видимому, является обычным явлением с SourceSafe. Можно ли использовать SourceSafe успешно, без проблем, и если да, то как?
version-control
billy.bob
источник
источник
Ответы:
На мой взгляд, просто перейти на что-то еще как можно скорее. Это не займет много времени (1-2 недели WAG), и независимо от того, сколько времени займет миграция, это легко оправдать затратами для руководства. Небольшое время для перехода приравнивается к надежному контролю исходного кода и очень небольшому риску потери исходного кода. Если ваш начальник настроен скептически, сделайте быстрый поиск в Google, чтобы найти "источник безопасных страшных историй" или подобное.
источник
Наихудший. SCM. Когда-либо.
Все, что не так в SCM, воплощено в VSS. Даже StarTeam лучше, чем Source Safe. Source Safe - это Internet Explorer 1 в мире контроля версий: он полностью заменен любой другой реализацией.
Как я это использовал?
Мой типичный рабочий процесс для достижения цели был
По сравнению с Subversion, вышесказанное смешно (кроме проверки, что вы не сломали сборку).
Ограничения в программировании моей команды
Это те правила, по которым команда должна была работать, чтобы она работала для нас. Ваш пробег может варьироваться.
Что может быть сделано?
У Polarion есть хороший набор инструментов для перехода с Source Safe на Subversion (SVN), который является текущим стандартом де-факто на большинстве предприятий для управления версиями с открытым исходным кодом. Subversion страдает от того, что сервер должен быть доступен для регистрации (в отличие от GIT или Mercurial, которые предназначены для распределенных автономных команд).
источник
Измените контроль исходного кода на SVN / Mercurial / Git и никогда не оглядывайтесь назад
источник
Мы сняли его с эксплуатации около года назад.
Несколько раз случалось так, что то, что я зарегистрировал прошлым вечером, просто не было там на следующее утро. Я не нашел это забавным, потому что это выглядело подозрительно, как будто я просто не закончил свою работу. Поскольку я был новичком в компании, это могло быть опасно для меня.
Мы перешли к TFS, и с тех пор она работает без сбоев.
источник
Мой вид?
Есть лучшие, которые проще в использовании, безопаснее и абсолютно бесплатны. Зачем вообще его использовать?
Это одна из областей развития, где у нас есть большой выбор; большинство или все лучше, чем VSS.
источник
Использование SourceSafe в коммерческой деятельности похоже на отопление здания путем сжигания долларовых купюр.
В 2000 году моя компания из восьми разработчиков, вероятно, потеряла 5-10% своей производительности из-за повреждения базы данных VSS в среднем два раза в день. Это было только так низко, потому что мы пошли на почасовые резервные копии.
С тех пор, как я перешел с VSS на Perforce, svn и git, у меня никогда не было поврежденной базы данных SCM.
источник
Я могу проголосовать за это, но ..
VSS эффективно помещает вас в допинг, до такой степени, что вы не можете примирить какую-либо реальность, необходимую, чтобы понять, что ваше теперь испорченное репо не было вашей ошибкой.
Пожалуйста, не используйте его, никогда.
источник
использовал его годами - это было решение по умолчанию, так как оно уже было. Если бы это укусило меня довольно много раз, но инерцию трудно преодолеть
затем мне пришлось использовать его удаленно через VPN, и даже незначительные проверки были похожи на то, как забить кирпич через дыру . Это было быстрее, чтобы вручную найти файлы, которые изменились, заархивировать их, отправить их по электронной почте, удаленно на компьютер с исходным хранилищем, распаковать их и проверить код с компьютера с исходным хранилищем.
Перешел на Mercurial. Я могу клонировать всю базу исходного кода через VPN менее чем за минуту. И я больше не боюсь ветвления.
Никогда не вернусь.
источник
Это мерзость Но все же лучше, чем ничего.
источник
Я использовал его в течение долгого времени (почти 10 лет), не сталкиваясь с какими-либо проблемами лично (в том числе в командах, в которых я работал, хотя наш код был довольно хорошо разделен, чтобы избежать конфликтов и тому подобного).
Но существует слишком много историй о потере данных, чтобы продолжать использовать их, когда есть достойные, надежные альтернативы с открытым исходным кодом.
Изменить: Из комментариев сообщение, кажется, избежать чего-либо сложного (ветвление, слияние, конфликты), и вы, вероятно, в порядке. Что-нибудь еще, и вы направляетесь на рискованную территорию.
источник
Даже MS осуждает это в пользу TFS.
Для сольного или действительно небольшого магазина, работающего в Visual Studio 6 или чего-то более старого, это сносно и лучше, чем ничего. Я думаю, что есть много преувеличений о том, как все было плохо, но тогда достаточно одного случая потери ценной работы, чтобы испортить вам продукт (по уважительной причине). У VSS было свое место, и я благодарен ему за то, что он по крайней мере поощрял многих разработчиков, которые вообще не использовали инструмент SCM, чтобы привыкнуть к этому, но, как и многие технологии, сейчас он в значительной степени устарел.
источник
После 3 лет его использования, время от времени жалуясь моему менеджеру из-за всех более продвинутых / рациональных альтернатив, у меня никогда не было проблем с VSS, но у меня никогда не было выбора.
Я считаю, что это и отстой, и от ударов.
Самая раздражающая часть об этом не в том, что это ужасное управление версиями и запутывающая способность ветвления, но список в меню файла не позволяет вам нажать правую клавишу со стрелкой для расширения.
Действительно больно.
источник
Мой взгляд на VSS? Я отказался от нескольких предложений работы (очень хорошо оплачиваемых), потому что они просили "VSS proficibility". И я уверен, что здесь есть пара других людей, которые сделали то же самое.
источник
Мало того, что вы страдаете от проблемы потенциального искажения источника (что должно быть достаточным аргументом, чтобы руководство могло его заменить), но вам также приходится жить с неуклюжим резервным копированием и неспособностью эффективно работать в команде в разных направлениях работы.
Найдите другой SCM (любой другой) и посмотрите, насколько легко могут быть ветвления и слияния. Подумайте о тех случаях, когда вам приходилось копировать файлы из вашего решения VSS и хранить их где-то еще, пока вы возвращались, чтобы исправить ошибку в «производственном» коде.
Для простоты просто установите GIT - укажите его на свои файлы VSS и посмотрите, как легко двум программистам GASP работать над разными частями одного и того же файла в одно и то же время, а затем заставить программное обеспечение разумно объединить ваши изменения ... SCM инструменты должны быть больше, чем просто резервное копирование источника.
источник
Мои взгляды на VSS? Использовал его в течение долгого времени регулярно (все еще иногда используется для старых компонентов), но для нашей команды это уже XX век:
Я согласен со всем вышеперечисленным: выберите один из лучших альтернатив с открытым исходным кодом (даже старый CVS) или, если у вашей компании есть какая-то подписка MSDN, TFS .
источник
Новый материал Team Foundation 2010 года должен был сильно помочь и попытаться уйти от плохих частей VSS.
Но по своей сути он все еще опирается на VSS, поэтому мы перешли на SVN.редактировать - я понимаю, что TFS - это все новое, но при тестировании многие разработчики, которых я спрашивал, испытывали очень похожие чувства. Причина, по которой я сказал «по своей сути», заключалась в том, что я помню, как просматривал файлы, созданные TFS в моем решении, которые выглядели так же, как те, что были созданы в VSS. Это с точки зрения разработчика, может быть, даже не зная о технологии, стоящей за VSS или TFS или любой другой SCM. Извините за путаницу.
источник
В тот день я был обременен SCCS под XENIX. VSS в Visual Studio 6 при всех его ошибках и проблемах имел явные преимущества. Я все еще использую его для небольших проектов и больше не использую SCCS в любой версии.
источник
Я не могу понять, почему все хотят ругать VSS. VSS не распространяется, а распределенный контроль версий
Пожалуйста, прочитайте это .
источник