Почему Visual SourceSafe просматривается так плохо? [закрытый]
Больше приема компилятора GCC, но можно дать подсказки признака ответвления компилятору (распространенный в ядре Linux)
#define likely(x) __builtin_expect((x),1)
#define unlikely(x) __builtin_expect((x),0)
, см.: http://kerneltrap.org/node/4705
, Что я люблю приблизительно, это - то, что это также добавляет некоторую выразительность к некоторым функциям.
void foo(int arg)
{
if (unlikely(arg == 0)) {
do_this();
return;
}
do_that();
...
}
11 ответов
Здесь длинный список проблем (правда, с 2002 года, но с тех пор продукт практически не изменился)
Изменить: вот текст из ссылки, на случай, если он исчезнет. Пейдж имеет лицензию CCA3.
Visual SourceSafe: Система уничтожения исходного кода Microsoft
Алан Де Смет
Есть много хороших решений для систем контроля версий. SourceSafe не работает один из них.
Я использовал SourceSafe пять лет, хотя и весной 2002 года. Он последовательно был неприятный опыт. Новые версии не смогли улучшить ничего из импорта. Я надеюсь отговорить вас от использования SourceSafe, избавляя вас от плохого опыта, который у меня был.
Недостающие функции
SourceSafe не хватает удобной поддержки ветвления
Система контроля версий должна обеспечивать мощное ветвление поддержка. Благодаря сильной поддержке ветвления разработчики могут легко вносить незначительные изменения в старые версии, работая над следующей основной выпуск продолжается. Можно проверить экспериментальный код в ветку, отделив ее от основной разработки но сделать резервную копию и сделать доступной для других разработчиков. Если проект «заморожен» в то время как этапный или финальный выпуск построен, разработчик может продолжить разработку к следующему версия на ветке. (Или, чаще, новая ветка может быть создан для заморозки, в то время как общее развитие продолжается Основная отрасль. Когда релиз сделан, изменения на замороженном ветку можно снова объединить с основной веткой.) SourceSafe's Поддержка ветвления не может эффективно поддерживать все это.
С мощным ветвлением система контроля версий должна также обеспечить сильную поддержку слияния для согласования различных ветви. По крайней мере, система должна позволять разработчику изучить различия между двумя ветками, изменить их, чтобы создайте объединенную версию и, когда будете удовлетворены, зарегистрируйте их. Поддержка слияния SourceSafe тесно интегрирована с проверкой в, что затрудняет изучение различий и тестирование предлагается объединить перед тем, как закрепить его в дереве. С этим слабым уровень поддержки, неработающий код легко проверить на система контроля версий.
SourceSafe не может быть расширен безопасно
Должна быть возможность легко расширить ваш контроль версий система с дополнительным функционалом. Возможность рассылки электронные письма, содержащие сводные данные о проверках, имеют важное значение. При работе с команда, регулярные сообщения электронной почты со списком зарегистрированных файлов и отмечать связанные с ними сообщения действительно помогают всем в курсе последних изменений. Вы также можете добавить фильтры для предотвращения проверки кода, который не соответствует определенным требования (стандартные заявления об авторских правах или не компилируются). SourceSafe едва ли поддерживает это. Хотя это возможно, каждый клиенту необходимо установить дополнительные функции. Если у одного клиента нет расширения, он незаметно не сможет веди себя как положено. (Подробнее см. Visual SourceSafe 6.0 Автоматизация . Проверьте раздел «Перехват событий SourceSafe? Обзор».) Вы можете платить даже подробнее для стороннего решения, но имеет ли смысл вкладывать больше денег в принципиально неработающий продукт?
SourceSafe незаметно оставляет устаревшие файлы в вашей локальной системе
При обновлении локального рабочего пространства для соответствия серверу файлы которые были удалены на сервере, должны быть перенесены на ваш внимание. (Или удалили, так как старую версию можно восстановить от системы контроля версий.) Невыполнение этого требования может привести к date, которые используются в вашем проекте, часто вызывая проблемы. Я часто сталкивался с этой проблемой, когда устаревший заголовок файл неправильно включен в мой проект. SourceSafe не работает для удаления устаревшего файла или предоставления какого-либо предупреждения.
SourceSafe плохо справляется с медленными сетями и общедоступным Интернетом
SourceSafe невозможно использовать при медленных сетевых соединениях. Это фактически непригоден для использования в общедоступном Интернете. К тому же, поскольку SourceSafe работает через общие сетевые ресурсы, если вы разместите Сервер SourceSafe в Интернете, вы обнаружите любые слабые места в реализации обмена файлами на ваших серверах по всему миру. Конечно, если вы готовы вложить больше денег в свою неэффективную ревизию система управления, вы можете купить стороннюю продукт для решения этой проблемы.
Управление модулями сторонних производителей с помощью SourceSafe затруднено
Разработчики нередко используют модули сторонних производителей. в свой проект, чтобы быстро добавить необходимые функции. За Например, вы можете использовать Xtreme Codejock Software Инструментарий . Естественно проверить эти сторонние модули в вашу систему контроля версий. Таким образом, когда вы ступите назад во времени, чтобы изучить предыдущую ревизию, вы можете получить одинаковые версии поддерживающих библиотек и сторонних модулей которые использовались для создания вашего кода в это время.
К сожалению, SourceSafe отслеживает сторонний модуль крайне сложно. Первоначальная проверка первой версии в не сложно. Проверка новой версии требует хорошей памяти и внимание к деталям. Чтобы добавить новую версию, вы сначала рекурсивно проверьте папку, в которой находится модуль. Теперь удалите каталог на диске и замените его новой версией. Регистрироваться новая версия в. Теперь вам нужно идентифицировать любые файлы или каталоги добавлены в новой версии. Щелкните правой кнопкой мыши папку модуля в SourceSafe и используйте "Показать разницу", чтобы рекурсивно сгенерировать список добавленных файлов. Запись какие каталоги содержат файлы, которые были добавлены, а какие каталоги добавлены. Теперь закройте отчет о различиях (отчет является модальным, поэтому вы не можете использовать SourceSafe, пока видимый). Добавьте новые каталоги, как обычно. каталоги. Чтобы добавить новые файлы, посетите каждый каталог, содержащий новые файлы и используйте Файл> Добавить файлы, чтобы добавить их. Опять же, используйте Команда "Показать разницу" для рекурсивного создания списка файлов которые были удалены. Отметьте эти файлы и закройте отчет о различиях снова. Теперь удалите каждый из этих файлов в SourceSafe.
Если вы действительно настроили сторонний модуль, SourceSafe не оказывает особой помощи в отслеживании различий и объединение их в новую версию.
(Для сравнения, чтобы проверить новую версию сторонней модуль с использованием CVS , вы бы просто запустите команду «cvs -q import -m» Импорт Xtreme Toolkit 1.9 'xtremetoolkit Codejock XT_1_9 ". Вот и все. Если вы внесли изменения в модуль, который необходимо интегрировать, вы будет использовать "cvs checkout -j XT_1_8 -j XT_1_9 xtremetoolkit ". Это даст вам локальную копию объединенные изменения, которые вы можете сразу проверить, если удовлетворительно.))
Просмотр и извлечение исторических версий чрезвычайно медленный
Нет ничего необычного в том, чтобы получить историческую версию исходный код. Вам может понадобиться более старая версия, чтобы исследовать отчет об ошибке, или текущий код работает неправильно, и вам необходимо получить работающую версию. SourceSafe поддерживает это, но крайне медленно для нетривиальных проектов. Чтобы получить исторический версии, вам сначала нужно сгенерировать историю для всего интересующий вас проект. В проекте с сотнями файлы и история чуть более одного года, это может легко занять более пяти минут (даже если вы ограничите фактический поиск за последние 48 часов изменений). После создания этой истории вы укажите версию, которую нужно получить, выбрав последнюю отметку для принять. Медленная скорость, с которой этот процесс завершается отговаривает разработчиков от изучения предыдущих версий, во многом побеждает цель системы контроля версий.
Трудно поддерживать несколько локальных копий одной проект
Внося обширные изменения в копию проекта, вы могут попросить внести в проект небольшие изменения. Большинство эффективный и безопасный способ сделать это - получить еще одну копию проект, в который нужно внести изменения. SourceSafe представляет две проблемы при этом. Во-первых, SourceSafe распознает только одну копию проект в вашей системе. Вам нужно будет либо переместить каталоги проектов туда, где SourceSafe ожидает канонических копии, или вам нужно будет сбросить SourceSafe представление о том, где каноническая копия существует. Используя любую технику, легко случайно укажите SourceSafe не на тот проект и проверьте неправильные версии файлов. Во-вторых, слабое слияние SourceSafe функции означают, что если вам нужно изменить один и тот же файл в обоих копии проекта, вам нужно быть очень осторожным, чтобы изменения в одном проекте не уничтожают изменения в другом.
Безопасность
SourceSafe ухудшается в больших проектах
Microsoft рекомендует, чтобы размер вашей базы данных не превышал 5 ГБ. (Источник: Рекомендации Microsoft ) Хотя это большая база данных, это не лишено смысла для большого проект, особенно если вы проверяете большие двоичные файлы (например, Документы Microsoft Word).
Интеграция SourceSafe может привести к сбою Visual Studio
SourceSafe может зависнуть или дать сбой, когда ваша система потеряет соединение в базу данных SourceSafe. Хотя это раздражает Visual SourceSafe, это может привести к потере работы, когда Visual Studio с использованием интеграции SourceSafe. Простое управление SourceSafe проекта, открытого в Visual Studio, достаточно, чтобы открыть себя для риск. Чтобы минимизировать этот риск (и ускорить ClassView), я предлагаю ты подписаться Указания Microsoft по отключению интеграции SourceSafe .
SourceSafe полагается на совместное использование опасных файлов
SourceSafe на самом деле работает не как сервер, а как набор файлы, передаваемые через SMB. В результате вы полагаетесь на каждый индивидуальный клиент, чтобы не вести себя плохо. Единственное плохое поведение компьютер может уничтожить базу данных. Проблема в обмене файлами реализация в вашей операционной системе может повредить базу данных. Пользователи, которым нужен только доступ для чтения доступ к системе контроля версий требует доступа на запись к сервер, увеличивая риск ( Требуемые сетевые права для каталогов SourceSafe ).
SourceSafe следует проверять на наличие повреждений еженедельно
Конечно, с таким высоким риском коррупции, Microsoft рекомендует запустить диагностическую программу Analyze. еженедельно. (Источник: Рекомендации Microsoft ) Пока работает Analyze, все ваши разработчики заблокировано вне системы (надеюсь, все вспомнили, что нужно выйти из SourceSafe в первую очередь!). Мой опыт работы с шоу SourceSafe что для 2-гигабайтной системы, работающей под Windows 2000, требуется несколько часов, чтобы проверить, запускается ли он еженедельно.
SourceSafe плохо обрабатывает несколько часовых поясов
Если у вас есть команды, использующие один и тот же репозиторий SourceSafe в разные часовые пояса, у вас могут возникнуть проблемы. ( См. Подробности Microsoft об ошибке часового пояса. ) Единственные решения Microsoft предлагает неправильную установку часов компьютеры в одном часовом поясе или купить у третьей стороны продукт.
Соответственно, это потенциальная проблема, если какой-либо из клиентов компьютеры, использующие SourceSafe, не могут синхронизировать часы. Разница в несколько минут между компьютерами может вызвать странное поведение SourceSafe с ним пытается примирить информация, которая, кажется, исходит из будущего.
SourceSafe поврежден
Ваша система контроля версий должна быть надежной. Вы доверив свою тяжелую работу вашей системе контроля версий. Если ваши данные повреждены, система бесполезна. SourceSafe's фундаментальный дизайн предполагает, что клиенты заслуживают доверия, всегда работают правильно, и что ничто не мешает связь, вызывающая повреждение данных. В результате SourceSafe хрупкий и ненадежный. Я работал с SourceSafe на три разные работы. В каждом случае в конечном итоге SourceSafe база данных повреждена. Данные повреждены, работа прервалась. потеряно, время было потрачено на решение проблемы. Разговаривая с других разработчиков, я узнал, что мой опыт не уникальный.
Раздражение
Мелкие действия, такие как изменение каталога, стирают все содержимое окна вывода, что затрудняет просмотр прошлого действия.
Сравнение вашей локальной версии с удаленным репозиторием - это неуклюжий. Вы выбираете интересующий вас каталог в SourceSafe и выберите Сравнить различия. Итоговый отчет является модальным, мешает вам работать с SourceSafe при изучении report.
При получении последней версии файлов из SourceSafe, каждый файл, измененный локально, вызывает всплывающее диалоговое окно для подтверждения обновление. Действие обновления полностью прекращается, пока диалог ждет вашего ответа. Это особенно раздражает, если вы получите последнюю версию, отойдите на время от компьютера, затем вернитесь и обнаружите, что SourceSafe готов только на 10% и жду вашего ответа. Вы можете запретить диалог вернуться несколькими способами, но при этом вы получите нет указание на то, что были обнаружены такие файлы. Итак, когда вы вернитесь к готовому обновлению, вы даже не догадываетесь, что SourceSafe обнаружил потенциальные проблемы. SourceSafe должен обратите внимание на эти файлы в окне вывода при обнаружении, сделав его легко сканировать окно вывода на предмет файлов, которые нужно исследовать.
Заключение
Если вы рассматриваете SourceSafe, подумайте о другом. Если вы используете SourceSafe сейчас, мигрируйте как можно скорее. Вот лишь некоторые из них.
Если вам просто необходимо использовать SourceSafe, определенно найдите время, чтобы посмотрите список Microsoft ошибок в списке Visual SourceSafe 6.0 и исправленных ошибок в Visual SourceSafe 6.0 , так что вы знаете, что делать ожидать. (Эти ссылки были изначально взяты со страницы Ошибки Microsoft . Эта страница может быть полезна, если у вас другая версия SourceSafe или указанные выше ссылки не работают.)
Эмпирически нет смысла доверять свой драгоценный исходный код программе, которая даже не дотягивает до такого уровня надежности, как Microsoft Access. Этот продукт нужно было выбросить много лет назад. Это просто не соответствует современным стандартам.
Я бы поставил его ниже любого продукта с открытым исходным кодом, такого как CVS или SVN, и я не знаю ни одного продукта, который я бы оценил ниже него, кроме, возможно, более старой версии VSS.
Самая большая проблема, с которой я столкнулся лично, - это повреждение базы данных . Бывает и больно. Кроме того, это довольно медленно по сравнению с более современными SCM.
На вашем месте я бы рекомендовал перейти как минимум на TFS. Интеграция с VisualStudio столь же тесна, она намного быстрее, и идиома почти такая же. У меня не было проблем с ним за 4 года, которые я им использую. Perforce - это дорогое удовольствие, и, вероятно, это не то, что нужно обсуждать в интервью.
В 2002/2003 годах на прежней работе я оказался тем парнем, которому пришлось присматривать за нашей установкой VSS.
Мы предоставили VSS собственный выделенный сервер - настоящее физическое оборудование - в чтобы свести к минимуму сбои, и все же у нас были регулярные проблемы.
Раз в неделю мне приходилось идти и чинить сломанные замки - блокировки, которые не мог быть выпущен разработчиком, который их установил.
Примерно два раза в год я делал это. для восстановления из поврежденного репозитория - казалось, что существует какое-то встроенное ограничение на отметке в 1 Гбайт, всякий раз, когда репозиторий значительно превышал 1 Гбайт, все довольно быстро становилось плохо.
Учитывая, что есть лучшие инструменты - с лучшей интеграцией - которые теперь доступны по нулевой цене, переход с VSS (для меня) не составляет труда.
SourceSafe - устаревшая технология, основанная на общих ресурсах Windows. Механизм хранения (нетранзакционные «плоские файлы») - это рецепт низкой производительности и ошибок. Его принятие не имеет ничего общего с тем, что у него есть над другими SCM, и все связано с тем фактом, что он «уже был там».
Я не могу комментировать Perforce, но могу сказать, что VSS по сравнению, скажем, с , Team Foundation Server - очень слабое предложение, и его следует использовать только в тех случаях, когда в него уже вложены большие средства и деньги нельзя потратить.
. Я согласен с тем, что VSS - это ужасная программа, но помимо возможной проблемы с повреждением базы данных, похоже, что ваша ситуация изменится. быть трудным для продажи людей. Например, вы не можете сказать, что VSS имеет ужасную поддержку слияния, потому что, ну, вы единственный разработчик. По той же причине нельзя жаловаться на блокировку касс. Если ваше приложение не имеет достаточно хорошего размера, вы не можете спорить с предлагаемым максимальным размером базы данных 1 ГБ, который предлагает VSS.
Я лично считаю, что в интервью, как вы предлагаете, вам было бы лучше искать более низкие плоды, чтобы предложить такие как итеративная разработка, TDD или вики для документации. Я хорошо боролся за переход от VSS к Perforce в корпоративной ситуации, и это было достаточно сложно. Я не могу представить себе попытку убедить руководство в серьезном изменении системы контроля версий в приложении, в котором есть один разработчик. YMMV.
Microsoft не использует его для внутренних целей. Вместо этого они получили лицензию на исходный код Perforce и взломали ее под свои нужды. Это красноречиво, поскольку Microsoft с гордостью тестирует другие свои продукты, такие как Windows и Office.
Мой последний опыт работы с Sourcesafe был много лет назад, так что отнеситесь к этому с недоверием. По моему опыту, это не очень хорошо масштабируется, поскольку количество разработчиков, использующих один и тот же код, растет.
Невозможно, чтобы несколько человек работали над одним и тем же кодом, а затем объединяли свои изменения вместе при регистрации. Вместо этого каждый разработчик должен заблокировать файлы, над которыми он работает, в то время как другие разработчики не могут добиться прогресса ни в чем, касающемся этих же файлов.
Потому что это делает ваш источник небезопасным, даже когда он находится в репозитории.
См. Также Better SCM Initiative: системы контроля версий, которых следует избегать .
Одна из проблем, о которых я читал там, и я пока не видел упомянутого в ответах, это то, что VSS не поддерживает удаленные, а затем воссозданные файлы : либо вы очищаете историю файла (и никогда не сможете восстановить старая версия), или вы можете создать файл с тем же именем, что и у удаленного файла. Даже CVS (которая также основана на файлах) попыталась сделать это правильно, используя область «Чердак».
- Повреждение кода (включая весь стек вашей истории)
- Повреждение двоичного файла (у нас была эта проблема специально с шаблонами PDF)
- Плохая интеграция в Visual Studio IDE (очень много ошибок)
- Постоянные блокировки файлов
- Я забыл упомянуть о повреждении репозитория ... eeek
- Нет ветвлений
Я могу продолжать и продолжать. Суть в том, чтобы полностью избегать этого продукта. Я думаю, что это может хорошо работать с небольшими проектами, но разработка приложений корпоративного уровня не должна включать решение постоянных проблем с репозиторием кодовой базы.