Следует ли разрешить разработчику использовать VSS, если он этого предпочитает?

Я познакомил Mercurial с моим отделом. Я люблю это, но это мой первый опыт контроля версий. Я использую его с PHP NetBeans для веб-разработки.

Другой разработчик, работающий с внутренними приложениями компании, любит использовать Visual Source Safe и не хочет переключаться. Он работает в среде Visual Studio.

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

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

Было бы лучше просто позволить ему продолжать использовать VSS, если это то, что он предпочитает, или было бы в интересах заинтересовать его в Mercurial?

было бы лучше просто позволить ему продолжать использовать VSS, если это то, что он предпочитает

Нет. Нет смысла запускать две разные системы управления источниками параллельно. Это противоречит самой идее о том, что все разработчики подключены к одному и тому же репозиторию и используют его в полной мере.

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

Еще одним аргументом здесь является удвоение усилий по обслуживанию обеих систем.

Я думаю, что вы должны использовать свои полномочия или передать проблему руководству, чтобы быстро перенести контент из VSS в Mercurial, а затем закрыть VSS.

PS Говоря о VSS, он печально известен тем, что проигрывает регистрации или иным образом повреждает код, когда вы меньше всего этого ожидаете. Это работает, но регулярно действует на нервы. Если у вас есть лучшая альтернатива, избегайте VSS.

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

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

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

Также VSS, как известно, глючит. Его код там даже не в безопасности.

Никто не должен использовать VSS для начала.

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

Все должны быть в одной системе управления источниками. Кроме того, ваша конечная цель - также привлечь всех к одной системе отслеживания ошибок. Вы правильно сделали, что уже нашли тесно интегрированное решение.

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

Собираюсь повторить то, что сказали другие, в том, что плохо позволять ему использовать VSS, а не Mercurial. Тем не менее, позвольте мне сыграть в «Адвоката дьявола» и сказать, что вы можете позволить ему сдвинуться с места, если и только если он все еще использует Mercurial, чтобы другие могли получить доступ к его работе, если это необходимо. В IMO нет ничего плохого в использовании предпочитаемых вами инструментов, если вы не мешаете другим получить доступ к работе, которая им может понадобиться. Конечно, VSS - это мусор, поэтому его не следует использовать ни на что :)

Например, я работаю в компании, которая использует SVN, но не имеет должным образом настроенного хранилища (без веток / тегов / ствола, все просто создается в одном хранилище), и это вызывает некоторые проблемы, которые никто не знает, как исправить. Я не увидел бы проблемы в моем случае, если бы я использовал, скажем, Git локально, но все еще использовал git-svn для передачи своих вещей в SVN, чтобы остальная часть команды имела это. Имеет ли это смысл?

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