재 작성을위한 버전 관리 실습

우리는 언어 X에서 제품 (시제품) P_OLD를 개발했으며 이제 언어 Y에서 P_NEW로 처음부터 다시 작성하고 있습니다.

P_NEW와 P_OLD는 동일한 제품이므로

P_NEW는 P_OLD old의 자랑이거나 자체 저장소 여야합니까?

버전 관리 관점에서 이러한 큰 변화를 처리하는 일반적인 방법은 무엇입니까?

당신은 거의 확실히 새로운 저장소를 원합니다.

저장소의 목적은 다음과 같습니다.

• 기록 및 변경 사항을 추적하여 쉽게 비교할 수 있습니다.
• 패치 파일을 이메일로 보내고 작업 디렉토리에 수동으로 적용하지 않고 분기 및 병합을 관리합니다.

프로젝트를 처음부터 완전히 다시 작성하는 경우 다시 작성을 동일한 저장소에 넣을 필요가 없습니다. 이전 언어로 작성된 패치를 다시 작성할 때 적용 할 수 없습니다. 리포지토리를 전환해도 이전 리포지토리의 기록이 사라지지 않으며, 전환하면 리포지토리에서 두 언어가 시작되는 이상한 중간 단계가 없습니다.

언어를 변경할 때 리포지토리를 유지하는 유일한 이유는 a) 언어가 너무 유사하여 코드를 변경하지 않고 한 코드에서 다른 코드로 복사하여 붙여 넣을 수 있거나 b) 프로젝트가있는 경우입니다. 버전 관리의 기능적 콘텐츠의 대부분은 유지하고있는 템플릿 언어의 템플릿과 같은 언어이며, 변경하는 핵심 언어는 한 줄씩 다른 언어로 번역됩니다. 마이그레이션하는 동안 템플릿을 계속 반복해야합니다.

나는 항상 새로운 저장소에 다시 씁니다. 그렇게하면 빌드, 테스트 및 배포를 모두 독립적으로 수행 할 수 있습니다.

다른 언어로 프로젝트를 재 작성할 때는 빌드, 테스트 실행 및 배포와 같은 작업에서 유사성이 거의없는 경우가 많습니다. 자신의 저장소에서 분리하면 고통을 줄일 수 있습니다. 그런 다음 기존 시스템에서 새로운 시스템으로 사용자 및 데이터 전환을 관리하는 방법에 대한 고통 만 걱정하면됩니다. 항상 재미있는 일입니다. :)

시스템이 충분히 모듈 식이고 링크 호환 가능한 경우 단일 리포지토리 및 빌드의 이점이 있습니다. 예를 들어 C 시스템을 C ++로 다시 작성하는 경우 C ++ 코드는 기존 기능을 호출하고 점진적으로 대체 할 수 있습니다.

그러나이 경우에도 일부는 필요에 따라 관련 이전 코드를 가져 오는 새 저장소를 시작한다고 주장 할 수 있습니다.