별도의 저장소에 코드와 데이터를 보관하는 것에 대한 장단점

Question

우리는 하나의 Mercurial 저장소에 번들 된 데이터와 코드를 가진 프로젝트를 가지고 있습니다. 데이터는 코드와 마찬가지로 중요합니다 (비즈니스 로직, 일부 입력 등을위한 매개 변수를 포함합니다). 그러나 데이터 파일의 형식은 거의 변경되지 않으며 데이터 파일을 코드와 독립적으로 변경하는 것이 좋습니다.

통합 저장소의 장점 중 하나는 여러 개정을 추적 할 필요가 없다는 것입니다. 이전 실행의 결과를 다시 작성해야 할 경우 시스템에 저장된 단일 개정 번호로 시스템을 업데이트하면됩니다 출력 로그.

하나의 단점은 여러 헤드가 활성화 된 상태에서 데이터를 수정하면 수동으로 변경 사항을 각 헤드에 복사하지 않으면 데이터가 손실 될 수 있다는 것입니다.

코드와 데이터를 별도의 리포지토리로 나누는 데있어 다른 장점이나 단점이 있습니까?

Answer 1

복수의 repos :

• 프로 :

  • component-based approach
  • 구성 사양 (독립적으로 서로를 발전 할 수있는 파일의 그룹을 식별) : 당신에게 당신에게 필요한 참조 (여기 "개정판")를 열거하십시오. r 시스템이 작동합니다. 한 파트를 변경하지 않고 한 파트를 수정하려면 해당리스트를 업데이트하십시오.
  • 부분 클론 : 당신이 모든 구성 요소가 필요하지 않은 경우, 당신은 단지
    • 구성 관리 (귀하의 경우에는 적용되지 않음)

  • 단점 당신이 원하는 사람을 복제 할 수 있습니다 : 해당 구성을 추적해야합니다 (보통 부모 저장소를 통해 subrepos을 등록)

  • 경우에 따라 데이터가 특정 버전의 프로젝트에 상당히 의존합니다 (이전 버전과는 다른 새로운 데이터를 가질 수 있습니다 프로젝트의 이온)

---

하나의 repo

• 프로
  • system-based approach : 당신이 하나 개의 시스템 (프로젝트와 데이터로 모듈을 참조).
  • REPO 관리 :
• 단점
  • 데이터 전달 (당신이 언급으로 할 때, 여러 HEAD는 (할 수있는 데이터의 의미가) 모듈 사이의 모든 하나 개
  • 꽉 링크 활성)
  • 중간 수정 버전 (새로운 기능을 반영하지 않고 일부 데이터가 변경된 것임)
  • 큰 복제본 데이터가 자주 변경) 비 - 바이너리 데이터의 경우

을, 큰 바이너리를 포함하지 않는 한, 나는 여전히 같은 REPO에 보관한다.

Answer 2

예. 코드와 데이터를 구분해야합니다. 버전 관리에서 코드를 유지하고 데이터베이스에서 데이터를 유지합니다.

나는 프로그래머이기 때문에 버전 관리가 좋아 10 년이 넘었고 나는이 일을 좋아합니다.

그러나 지난 몇 개월 동안 나는 깨달았습니다 : 데이터는 버전 제어가되어서는 안됩니다. 때때로 git (또는 다른 버전 제어 시스템)에 익숙한 사람이 "놓아두기"어렵습니다.

데이터베이스 스키마 마이그레이션을 지원하는 좋은 ORM이 필요합니다. 마이그레이션 (스키마 마이그레이션 및 데이터 마이그레이션)은 버전 관리에서 유지되지만 데이터는 유지되지 않습니다.

나는 하나 또는 두 개의 저장소를 사용하는 것에 관한 것이었지만, 아마도 내 대답은 다른 관점을 얻는 데 도움이 될 것입니다.