Почему Visual SourceSafe так плохо просматривается?

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

Я бы оценил его ниже любого продукта с открытым исходным кодом, такого как CVS или SVN, и я не знаю ни одного продукта, который я бы оценил ниже него, кроме, возможно, более старой версии VSS.

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

На вашем месте я бы рекомендовал перейти хотя бы на TFS. Интеграция с VisualStudio столь же тесна, она намного быстрее, и идиома почти такая же. У меня не было проблем с ним за 4 года, которые я им использую. Perforce - это дорогое удовольствие, и, вероятно, это не то, что нужно обсуждать на собеседовании.

Еще в 2002/2003 году на прежней работе я оказался тем парнем, которому пришлось присматривать за нашей установкой VSS.

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

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

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

Учитывая, что есть лучшие инструменты - с лучшей интеграцией - которые теперь доступны по нулевой цене, переход с VSS (для меня) не составляет труда.

Я согласен с тем, что VSS - ужасная программа, но, помимо возможной проблемы с повреждением базы данных, похоже, что ваша ситуация будет сложной для людей. Например, вы не можете сказать, что VSS имеет ужасную поддержку слияния, потому что вы единственный разработчик. По той же причине нельзя жаловаться на блокировку кассовых аппаратов. Если ваше приложение не имеет достаточно хорошего размера, вы не можете спорить с предлагаемым максимальным размером базы данных 1 ГБ, который предлагает VSS.

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

SourceSafe - устаревшая технология, основанная на общих ресурсах Windows. Механизм хранения (нетранзакционные «плоские файлы») - это рецепт низкой производительности и ошибок. Его принятие не имеет ничего общего с тем, что у него есть по сравнению с другими SCM, а все связано с тем фактом, что он «уже был там».

Я не могу комментировать Perforce, но могу сказать, что VSS по сравнению, скажем, с Team Foundation Server - очень слабое предложение, и его следует использовать только в тех случаях, когда в него уже вложены большие средства и НИКАКИХ денег нельзя потратить.

Microsoft не использует его для внутренних целей. Вместо этого они получили лицензию на исходный код Perforce и взломали ее под свои нужды. Это красноречиво, поскольку Microsoft с гордостью тестирует другие свои продукты, такие как Windows и Office.

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

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

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

Проблема, с которой я сейчас сталкиваюсь, заключается в том, что Visual Source Safe настаивает на том, что структура папок моего проекта не может быть представлена ​​в целевом рабочем каталоге. Он всегда думает, что проект установки службы пытается вторгнуться в проект службы, и отказывается регистрировать его. Когда вы добавляете проект в систему управления версиями, он неизменно добавляет другую папку к своему пути в системе управления версиями. Контроль версий должен просто представлять файловую структуру, которая УЖЕ РАБОТАЕТ на машине разработчика, без претензий.

См. Также Лучшая инициатива SCM: версия Системы управления, которых следует избегать.

Одна из проблем, о которых я читал там и не встречал упомянутых до сих пор в ответах, заключается в том, что VSS не поддерживает удаленные, а затем воссозданные файлы: либо вы очищаете историю файла (и никогда не сможете восстановить старую версию), или вы можете создать файл с тем же именем, что и у какого-то удаленного файла. Даже CVS (которая также является файловой) попыталась сделать это правильно, используя область «Чердак».

1. Повреждение кода (включая всю вашу историю)
2. Повреждение двоичного файла (у нас эта проблема была особенно с шаблонами PDF)
3. Плохая интеграция в Visual Studio IDE (очень глючит)
4. Постоянные блокировки файлов
5. Я забыл упомянуть о повреждении репозитория ... eeek
6. Нет ветвления

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