여러 Subversion 프로젝트 간의 관계 처리

StackOverflow https://stackoverflow.com/questions/1405091

문제

우리 회사에서는 하나의 SVN 저장소를 사용하여 C++ 코드를 보관하고 있습니다.코드 베이스는 공통 부분(인프라 및 애플리케이션)과 클라이언트 프로젝트(플러그인으로 개발)로 구성됩니다.

저장소 레이아웃은 다음과 같습니다.

  • 하부 구조
  • 앱1
  • 앱2
  • 앱3
  • 클라이언트를 위한 프로젝트-1
    • App1-플러그인
    • App2 플러그인
    • 구성
  • 클라이언트용 프로젝트-2
    • App1-플러그인
    • App2 플러그인
    • 구성

클라이언트 프로젝트의 일반적인 릴리스에는 프로젝트 데이터와 이에 사용되는 모든 프로젝트가 포함됩니다(예:하부 구조).

각 디렉토리의 실제 레이아웃은 다음과 같습니다.

  • 하부 구조
    • 가지
    • 태그
    • 트렁크
  • 클라이언트용 프로젝트-2
    • 가지
    • 태그
    • 트렁크

그리고 나머지 프로젝트도 마찬가지다.

위의 레이아웃에는 몇 가지 문제가 있습니다.

  1. 관련된 프로젝트를 모두 체크아웃해야 하기 때문에 클라이언트 프로젝트를 위한 새로운 개발 환경을 시작하기가 어렵습니다(예:인프라, 앱1, 앱2, 클라이언트용 프로젝트-1).
  2. 위와 같은 이유로 클라이언트 프로젝트의 릴리스에 태그를 지정하는 것은 어렵습니다.
  3. 클라이언트 프로젝트에서 일부 공통 코드를 변경해야 하는 경우(예:인프라), 때때로 지점을 사용합니다.프로젝트에서 어떤 분기가 사용되는지 추적하는 것은 어렵습니다.

SVN에서 위의 문제를 해결할 수 있는 방법이 있나요?클라이언트 프로젝트에서 svn:externals를 사용하려고 생각했지만 읽은 후에 이 게시물 나는 그것이 올바른 선택이 아닐 수도 있다는 것을 이해합니다.

도움이 되었습니까?

해결책

svn:externals를 사용하여 이 문제를 처리할 수 있습니다.이것은 SVN Repo의 지점에 대한 URL입니다. 다른 저장소 (또는 동일한 저장소)의 일부를 가져올 수 있습니다.이를 사용하는 한 가지 방법은 project-for-client2에서 필요한 인프라 분기, 필요한 app1 분기 등에 svn:externals 링크를 추가하는 것입니다.따라서 project-for-client2를 확인하면 올바른 부분을 모두 얻을 수 있습니다.

svn:externals 링크는 다른 모든 링크와 함께 버전이 지정되므로 project-for-client1에 태그가 지정되고 분기되고 업데이트되면 올바른 외부 분기가 항상 가져옵니다.

다른 팁

제안은 디렉토리 레이아웃을 다음에서 변경하는 것입니다.

  • 하부 구조
    • 가지
    • 태그
    • 트렁크
  • 클라이언트를 위한 프로젝트-1
    • 가지
    • 태그
    • 트렁크
  • 클라이언트용 프로젝트-2
    • 가지
    • 태그
    • 트렁크

에게

  • 가지
    • 기능-1
      • 하부 구조
      • 클라이언트를 위한 프로젝트-1
      • 클라이언트용 프로젝트-2
  • 태그
  • 트렁크
    • 하부 구조
    • 클라이언트를 위한 프로젝트-1
    • 클라이언트용 프로젝트-2

이 레이아웃에도 몇 가지 문제가 있습니다.브랜치는 거대해지지만 최소한 코드의 특정 위치에 태그를 지정하는 것이 더 쉽습니다.

코드 작업을 하려면 간단히 트렁크를 체크아웃하고 작업하면 됩니다.그러면 모든 다른 프로젝트를 확인하는 스크립트가 필요하지 않습니다.그들은 단지 "../Infrastructure"로 인프라를 참조합니다.이 레이아웃의 또 다른 문제점은 프로젝트를 완전히 독립적으로 작업하려면 여러 복사본을 체크아웃해야 한다는 것입니다.그렇지 않으면 한 프로젝트의 인프라가 변경되면 해당 인프라도 업데이트될 때까지 다른 프로젝트가 컴파일되지 않을 수 있습니다.

이로 인해 릴리스가 좀 더 번거로워지고 여러 프로젝트에 대한 코드가 분리될 수 있습니다.

그래, 짜증나. 우리는 똑같은 일을하지만 실제로 더 나은 레이아웃을 생각할 수는 없습니다.

따라서 우리가 가진 것은 모든 전복과 관련된 모든 스크립트 세트입니다. 각 고객의 프로젝트에는 호출되는 파일이 포함됩니다 project.list, 여기에는 해당 고객을 구축하는 데 필요한 모든 파괴 프로젝트/경로가 포함되어 있습니다. 예를 들어:

Infrastructure/trunk
LibraryA/trunk
LibraryB/branches/foo
CustomerC/trunk

그런 다음 각 스크립트는 다음과 같습니다.

for PROJ in $(cat project.list); do
    # execute commands here
done

명령이 체크 아웃, 업데이트 또는 태그 일 수있는 경우. 그것보다 조금 더 복잡하지만 모든 것이 일관성이 있고 체크 아웃, 업데이트 및 태깅이 단일 명령이된다는 것을 의미합니다.

물론, 우리는 가능한 한 적게 분기하려고 노력합니다. 이것은 내가 할 수있는 가장 중요한 제안입니다. 우리가 무언가를 분기해야한다면, 우리는 트렁크에서 벗어나거나 가능한 한 많은 종속성의 이전에 태그 된 버전을 벗어나려고 노력할 것입니다.

첫째, 나는 외부가 악하다는 데 동의하지 않습니다. 그들은 완벽하지는 않지만.

현재 작업 사본을 구축하기 위해 여러 체크 아웃을하고 있습니다. 외부를 사용하는 경우 정확히이 작업을 수행하지만 매번 자동 및 일관되게 수행합니다.

대상 프로젝트 내에서 외부를 태그 (또는 또는 특정 개정판)로 가리키면 릴리스 당 현재 프로젝트에만 태그를 지정하면됩니다 (태그는 외부를 가리키는 외부를 정확히 나타냅니다). 또한 특정 라이브러리의 새 버전을 사용하도록 외부 참조를 변경했을 때의 프로젝트 내에서도 기록이 있습니다.

외부는 만병 통치약이 아니며 게시물에서 알 수 있듯이 문제가있을 수 있습니다. 나는 외부인보다 더 좋은 것이 있다고 확신하지만 아직 (개념적으로도) 찾지 못했습니다. 확실히, 당신이 사용하는 구조는 개발 프로세스에서 많은 정보와 제어를 생성 할 수 있습니다. 외부를 사용하면이를 추가 할 수 있습니다. 그러나 그가 겪었던 문제는 근본적인 부패 문제가 아니 었습니다. 깨끗한 점은 모든 것을 해결하고 매우 드 rare니다.

고려해야 할 사항 - 재귀적인 외부를 사용합니다. 나는 이것의 예 또는 아니오에 팔리지 않았으며 실용적인 접근 방식으로가는 경향이 있습니다.

기사에서 알 수 있듯이 피스톤을 사용하는 것을 고려하십시오. 나는 그것을 실제로 보지 못했기 때문에 실제로 언급 할 수 없으며, 더 나은 방법으로 외부와 동일한 작업을 수행 할 수 있습니다.

내 경험을 통해 각 개별 프로젝트에 대한 저장소를 갖는 것이 더 유용하다고 생각합니다. 그렇지 않으면 다른 프로젝트가 변경되면 혼란 스러울 수있는 문제가 발생하고 개정 번호가 변경됩니다.

소프트웨어, 하드웨어 회로도, 문서 등과 같은 개별 프로젝트간에 관계가있을 때만 단일 저장소를 사용하므로 개정 번호가 전체 팩을 알려진 상태로 가져 오는 역할을합니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top