Потратив все утро, пытаясь что-то проверить - теперь я понимаю, что потерял пару дней работы.

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

На мой взгляд, просто перейти на что-то еще как можно скорее. Это не займет много времени (1-2 недели WAG), и независимо от того, сколько времени займет миграция, это легко оправдать затратами для руководства. Небольшое время для перехода приравнивается к надежному контролю исходного кода и очень небольшому риску потери исходного кода. Если ваш начальник настроен скептически, сделайте быстрый поиск в Google, чтобы найти "источник безопасных страшных историй" или подобное.

Наихудший. SCM. Когда-либо.

Все, что не так в SCM, воплощено в VSS. Даже StarTeam лучше, чем Source Safe. Source Safe - это Internet Explorer 1 в мире контроля версий: он полностью заменен любой другой реализацией.

Как я это использовал?

Мой типичный рабочий процесс для достижения цели был

1. Проверьте проект
2. Заблокируйте все файлы (чтобы не слиться с кем-либо, потому что он открыл нечестивые врата ада)
3. Сделал мою работу
4. Каждый день проверял мои изменения в
5. Проверил все обратно и исправил все проблемы с интеграцией
6. Проверил обратно

По сравнению с Subversion, вышесказанное смешно (кроме проверки, что вы не сломали сборку).

Ограничения в программировании моей команды

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

1. Только один человек может редактировать файл (Небеса помогут вам, если они уйдут в отпуск)
2. Не разветвляйте это слишком сложно управлять
3. Никогда не пытайтесь вернуться к предыдущей ревизии

Что может быть сделано?

У 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 .

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

Новый материал Team Foundation 2010 года должен был сильно помочь и попытаться уйти от плохих частей VSS. Но по своей сути он все еще опирается на VSS , поэтому мы перешли на SVN.

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

В тот день я был обременен SCCS под XENIX. VSS в Visual Studio 6 при всех его ошибках и проблемах имел явные преимущества. Я все еще использую его для небольших проектов и больше не использую SCCS в любой версии.

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

1. лучше
2. позволяет на практике распространять контроль версий

Пожалуйста, прочитайте это .