대부분의 팀에는 혁신에 저항하는 관성이 있다. 개인을 포함하여 모든 조직에는 기존의 공정이 이미 있을 것이며 심지어 기존의 업무 방식이 아주 나쁠 때에도 새로운 시스템의 도입은 반발을 야기하곤 한다. 때로는 도입 시점의 위험, 기존 도구의 익숙함, 어쩌면 감정적인 대립 등의 비용을 감수하는 것보다는 비효율적인 기존의 공정을 사용하는 것이 더 나을 수도 있다. 이것을 어떻게 판단할까?

가장 좋은 방법은 팀원들이 합리적인 판단을 하고 스스로 결정할 수 있도록 객관적인 정보를 제공하는 것이다. 그러나 새로운 시스템의 장점을 소개해도 '그런 기능이 왜 또 필요해? 이미 충분해' 라는 반응을 일으키기 십상이다. 따라서 새 시스템에 비한 기존 시스템의 단점을 알리고 여기서 팀원들의 공감대를 얻어내는 것이 좋다. 새 시스템의 소개는 그 다음에 한다.

여기에 이상적인 소스 컨트롤 모델을 가정할 때, Visual SourceSafe 6의 약점이라고 할 수 있는 점들을 정리한다.

• 여러 파일에 걸친 하나의 작업 내용을 한꺼번에 체크인할 때 파일마다 로그가 따로 달림
• 작업이 어느 정도 마무리된 후 체크아웃된 것들 중 어떤 파일이 고쳐졌는지 한 눈에 알 수 없음
• 소스 컨트롤에도 들어있고 로컬에서도 만들어지거나 수정되는 파일의 경우 관리의 어려움
  • 항상 체크아웃해두어야 하거나 Read Only 설정을 만져야 한다 - 이 경우 최신 소스를 얻을 때 불편함
  • IDL(또는 DDL) 파일들이나 라이브러리, 가끔은 리소스 파일(이미지, 사운드 등)도 여기에 해당
• 로그를 일목요연하게 볼 수 없음
  • 로그를 웹 등에서 볼 수 있으면 편함
  • 잘못된 코드를 체크인했을 때 복구가 편리
  • 한 번 고쳤던 코드가 되돌아갔을 때 원인 파악이 쉬움
  • 로그를 이용해 ChangeLog나 NEWS를 작성할 수 있음
  • 어떤 기능이 언제 들어갔는지 확인해서 그 버전 또는 그 이전 버전을 얻어야 할 필요가 가끔 있음
• VS IDE에 연결되어 있는 것이 편한듯 보이나 여기서 전부 처리되지 않고 SourceSafe 툴을 따로 띄워야 함
  • 특히 소스가 아닌 파일일 경우에는 VS IDE만으로 불가능
  • 전체 트리의 최신 소스를 가져올 때 별도 SourceSafe 툴을 사용해야 함
• 브랜치, 태깅 등이 불편
  • 기존 구조나 시스템이 바뀔 때 다른 사람의 작업을 방해하지 않기 위해 브랜치 후 작업해야 함
  • 브랜치에서 작업 후 머징하기 쉬움
• 소스 트리를 한 개 이상 받을 경우 사실상 작업이 어려움
  • 소스 컨트롤 시스템에서 깨끗한 소스를 받아서 아무 작업 없이 빌드가 되는지 확인할 때 필요
  • 브랜치 작업을 할 때 한 개 이상의 소스 트리를 사용할 필요가 있음
  • 작업이 실패했을 때 깨끗한 소스 트리가 있으면 일부 코드만 되돌리는 작업이 수월