회사는 다른 버전 제어 시스템을 사용하는 다른 회사를 인수합니다.
예를 들어 Subverson-GIT 브리지를 사용하거나 한 도구를 다른 도구로 사용하기로 결정하는 등 시스템을 통합하는 방법과 시스템 간 마이그레이션 방법에 대한 공통된 지식이 있습니까?
사람들은 그러한 의사 결정을 위해 소프트웨어 개발에 대한 "Joel"테스트와 같은 일련의 기준을 사용합니까?
회사는 다른 버전 제어 시스템을 사용하는 다른 회사를 인수합니다.
예를 들어 Subverson-GIT 브리지를 사용하거나 한 도구를 다른 도구로 사용하기로 결정하는 등 시스템을 통합하는 방법과 시스템 간 마이그레이션 방법에 대한 공통된 지식이 있습니까?
사람들은 그러한 의사 결정을 위해 소프트웨어 개발에 대한 "Joel"테스트와 같은 일련의 기준을 사용합니까?
답변:
여러 마이그레이션의 개인적인 경험에서 마이그레이션 질문에 대답하려면 다음을 수행하십시오.
현재 버전의 소프트웨어를 새로운 소스 제어 시스템에 기본 라인으로 넣고 거기서부터 작업하는 것을 두려워하지 마십시오.
대부분의 시간은 역사가 필요하지 않습니다. 즉, 통합 중에 수행해야 할 작업이 적고 잘못해야 할 일이 적습니다.
활발하게 개발중인 파일 / 프로젝트는 곧 새로운 역사를 만들어 낼 것입니다. 따라서 변경이 발생한 이유를 찾아야 할 경우 히스토리가 최근 변경 사항이므로 현재 저장소에있을 가능성이 있습니다.
마이그레이션 이전에 안정적인 파일 / 프로젝트는 마이그레이션 후에도 모든 것이 동일하게 유지되므로 기록을 참조 할 필요가 없습니다. 히스토리가있는 오래된 파일 / 프로젝트에서 버그를 조사해야한다면 실제로 아무런 이점이 없다는 것을 알았습니다. 이전 저장소를 1 년에 6 개월 동안 사용할 수있는 한 그러한 경우에 참조가 필요합니다.
경영 측면에서는 주로 다음과 같은 문제입니다.
프로젝트 측면에서도 다음과 같은 질문입니다.
프리웨어 여부에 상관없이 "무료 맥주"가 아닌 "무료 음성"(무료 음성) (원하는 것을 자유롭게 선택하여 배포 할 수 있음)과 같이 "무료"소프트웨어는 무료입니다 (서버에 많은 비용이 소요됨) , 백업, 관리, 지원 등)
위에서 언급 한 기준은 어떤 VCS를 유지할 것인지, 무엇을 버릴지를 결정하기위한 시작입니다.
그러나 후자의 경우 다음을 고려해야합니다.
다른 시스템을 통합해야합니까? 우리 팀에서 각 프로젝트는 자체 저장소에 존재하므로 그 역사는 독립적입니다. 우리는 여기에 종속이 있더라도 서브 버전의 프로젝트와 수은의 프로젝트를 다루는 데 아무런 문제가 없습니다.
한 VCS에서 다른 VCS로 마이그레이션하기로 선택한 경우 사용 가능한 변환 도구를 살펴보십시오. 내 경험으로는 프로젝트 기록을 삭제해야 할 기술적 이유가 없습니다.
나는 질문과 다른 답변에 암시 된 것을 이해했다고 생각합니다. VCS는 종속성을 관리하는 데에도 사용됩니다. svn:externals하나의 리포지토리 (종속성)를 다른 리포지토리 와 통합하는 것과 같은 VCS 기능을 사용하는 것이 일반적이라는 것을 알고 있습니다 .
우리 팀이 2 개의 다른 시스템을 연결 (또는 통합) 할 필요가 없다고 생각하는 (기술적 인) 이유는 의존성을 관리하는 별도의 도구가 있기 때문입니다. 우리의 레포는 서로를 모른다.
많은 좋은 답변입니다. 고려해야 할 또 다른 사항은 팀 구성원이 VC 전환을 생각하지 못하게하는 것입니다. 이주, 학습 곡선 등으로 인해 어려움이있을 수 있지만 문제가 너무 많으면 능력 및 / 또는 협력 수준에 의문을 제기해야합니다.