분기 공유 라이브러리에 대한 저장소 레이아웃 (또는 후크) (및 정신 유지)
https://stackoverflow.com/questions/1400199
-
05-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
우리는 전복을 사용하고 있습니다.
저장소 레이아웃은 다음과 같습니다.
(레이아웃 a)
Web
branches
tags
trunk
Libraries
Foo
branches
tags
trunk
Bar
branches
tags
trunk
WindowsClient
branches
tags
trunk
DB
branches
tags
trunk
문제는 버전화 단위가 개발 단위와 같지 않다는 것입니다. 제작 가능한 아티팩트를 얻으려면 여러 체크 아웃을해야하며 분기 할 때 여러 구성 요소를 분기해야합니다 (여러 장소에서 체크인).
이것은 대신 다음과 같은 구조로 이동할 수 있음을 의미합니다.
(레이아웃 b)
Web
branches
tags
trunk
main
libs
Foo
Bar
DB
WindowsClient
branches
tags
trunk
main
libs
Foo
Baz
DB
그러나 공유 라이브러리의 복제본이 있습니다. 우리는 SVN : Externals를 사용하는 데 공유 된 LIB를 매핑 할 수 있지만, 그것은 단지 환상 일뿐입니다. 포함 된 프로젝트가있을 때는 분기되지 않습니다.
최종 옵션은 이것입니다.
(레이아웃 C)
branches
tags
trunk
Web
Libraries
Foo
Bar
WindowsClient
DB
이것은 도서관이 포함 된 프로젝트와 함께 분기되어 있는지 확인하지만 분기 단위가 전 세계입니다. (이것은 또한 체크 아웃 단위가 전 세계이며, 이는 성가신 것임을 의미합니다.)
내가 원하는 것은 저장소 레이아웃입니다 (레이아웃 D) 그것은 내가 다음을 허용 할 수있게한다 :
- 프로젝트 및 종속 라이브러리를 한 번에 분기
- 프로젝트간에 라이브러리를 공유합니다
한 번의 체크 아웃에서 프로젝트와 라이브러리를 확인할 수 있다면 좋을 것입니다. 그러나 위의 것만 큼 중요하지는 않습니다.
그래서 문제는 다음과 같습니다.
레이아웃 D가 있습니까?
편집하다: 이 속성을 줄 기본 레이아웃이없는 것처럼 보이기 때문에, 나는 나를 거기에 데려다 줄 수있는 훅 기능에 매우 관심이있을 것입니다. 우리가 사용하는 것이기 때문에 TortoisesVN (Windows GUI) 클라이언트와 함께 작동한다면 특히 좋을 것입니다.
해결책
옵션 C와 함께 이동 한 다음 다음과 같은 체크 아웃을하십시오.
svn co -N ...../branches/mybranch workingcopy
cd workingcopy
svn update Web Libraries
이제 SVN 작업을 할 때 (평원 포함”svn update"), 그것은 단지 그것을 다룰 것입니다 Web 그리고 Libraries 디렉토리.
또한 읽으십시오 드문 디렉토리.
다른 팁
"이 워크 플로에 대한 저장소를 세우는 방법"이라는 질문에 대한 좋은 답은 없습니다. 소프트웨어가 실제로 지원하지 않기 때문입니다. 레이아웃 B를 사용하여 라이브러리 코드를 분기하고 관련성을 전환하는 것이 좋습니다. svn:external 필요에 따라 해당 지점에 또는 지점에서 트렁크 버전의 라이브러리를 참조 해야하는 경우 즉시.
나는 git이 이것을 더 잘 처리한다고 제안하려고했지만 그다지 많지는 않습니다. 서브 모듈은 외부와는 별도의 리포지토리를 약간 다르게 언급하고, 리포지토리의 각 사본은 '분기'이므로 약간의 개선 일 수 있습니다.
우리는 SVN : Externals를 사용하는 데 공유 된 LIB를 매핑 할 수 있지만, 그것은 단지 환상 일뿐입니다. 포함 된 프로젝트가있을 때는 분기되지 않습니다.
실제로, 그들은 분기 될 것입니다 그들이 같은 저장소에 있고 상대 외부 구문을 사용한 경우, 예를 들어 (편집하다: 나는 그것이 이런 식으로 작동했다고 확신했지만 그 행동을 재현 할 수없는 것 같습니다. 나는 실수했을 것이다, 죄송합니다!)^\mylib\trunk. 이러한 외부 참조는 정상 (복사 된) 폴더로 변경됩니다. 명시 적으로 통과해야합니다 --ignore-externals 에게 svn copy 이 동작을 억제하려면 그렇지 않으면 레이아웃 B와 같은 사본으로 끝납니다.
외부가 항상 자동으로 분기되지 않는다는 사실이 문제가 될 필요는 없습니다. 제작 된 레이아웃 B를 사용합니다 svn:externals (사본 아님), 프로젝트를 분기 --ignore-externals), 그 다음 분기 후 svn:externals 올바른 라이브러리 지점을 가리 킵니다.
외부를 설정하여 특정 개정을 가리킬 수 있습니다 (엄격한 제어에 적합합니다. LBRARY의 새로운 개정판으로 업그레이드 할시기를 결정 함) 또는 헤드를 추적 할 수 있습니다 (빌드 서버 세트가 있다고 가정하면 지속적인 통합에 적합합니다. 위로).
우리가 해결 한 방식은 여러 프로젝트에서 사용하는 공유 외부 라이브러리를위한 것입니다. 공유 라이브러리는 자체 트렁크/분기/태그와 함께 자체 저장소로 사용됩니다.
그런 다음 빌드 서버 빌드 및 게시 및 게시, 이정표 및 릴리스를 보유하고 있으며 이진 인공물은 공유 위치로 복사되어 버전 특정 디렉토리에 저장됩니다 (백업).
종속 프로젝트에 대한 빌드 스크립트의 일부 (일반적으로 표준 빌드의 일부가 아닌 Init/Update로서 요구에 따라 실행) 새로운 버전을 확인하고 이진을 잡습니다. 이는 종속 프로젝트 간의 공유 인공물의 일관된 버전화의 장점이 있으며 모든 종속 프로젝트가 동일한 버전을 공유 할 수 있으므로 빌드 시간을 줄입니다.
현재 사용중인 버전 작성을 돕기 위해 아파치 아이비 이는 과도 종속성 (예 : 종속성의 종속성을 가져 오기) 및 버전 제약 조건 (예 :이 프로젝트는 FOO 버전 1.2.*만 사용해야 함)과 같은 것을 지원합니다.
나는 당신의 문제를 일으키는이 라이브러리에 대한 당신의 접근 방식이라고 제안합니다. 라이브러리에 대해 별도의 프로젝트로 생각하기 시작하면이를 변경할 수 있습니다. 단위 테스트, XML 리더, DB 액세스 등에 사용할 수있는 타사 라이브러리와 마찬가지로 자체의 이유, 자체 디자인 및 릴리스주기에 대한 이유가 있다고 생각하십시오.
물론 프로젝트의 기능에 라이브러리에 새로운 기능이 필요한 시간이 정기적으로 있습니다. 라이브러리 기능을 구현하고 라이브러리 기능을 사용하는 것은 두 가지 독립적 인 작업입니다. 하나의 비즈니스 작업 일 수 있지만 두 가지 개발 작업입니다. 작업이 시작된 방식이기 때문에 두 가지 활동을 단단히 연결할 필요가 없습니다. 라이브러리 체크 아웃, 변경, 출시 다음 프로젝트를 확인하고 프로젝트에서 새로운 라이브러리 릴리스를 사용하십시오.
나는 도서관을 자신의 트렁크로 분리하는 것이 좋은 일이라고 강하게 느낍니다. 단일 트렁크 아래에 독립적으로 발표 가능한 여러 프로젝트를 볼 때 견딜 수 없습니다. 그것은 디자인이 열악하고 개발 cruft에 의해 코너로 뒷받침되었습니다. 그러나 그것들을 분리하려면 각 프로젝트를 독립적으로 공개 할 수 있어야합니다. 수단. 그러나하는 것은 어렵지 않습니다.
먼저 프로젝트는 외부를 사용하여 특정 릴리스 버전의 라이브러리를 참조합니다. 이것이 프로젝트가 라이브러리를 참조하는 유일한 방법입니다. 이렇게하면 개발자가 모든 프로젝트가 이전 버전을 참조하기 때문에 개발자가이를 사용하는 프로젝트를 중단하지 않고 새로운 버전의 라이브러리를 만들 수 있음을 의미합니다. 프로젝트는 새로운 버전의 라이브러리를 가져오고 싶을 때 제어 할 수 있습니다. 개발자는 새 버전으로 코드를 테스트하려는 노력을 기울이고 새로운 빌드 문제를 해결해야 할시기를 선택할 때 선택할 수 있습니다. 소개.
이와 같은 라이브러리의 버전을 명시 적으로 변경하면 프로젝트에서 "지금 사용하고 있습니다. 이것 도서관 X "의 버전은 프로젝트에서 일이 진행되는시기와 상황이 바뀌는시기에 대한 역사에 대한 좋은 역사를 제공합니다.
물론, 이것은 이론적으로는 모두 훌륭하지만 실제로 개발자는 때때로 불안정하고 미완성 된 버전의 라이브러리를 참조해야 할 것입니다. 괜찮습니다. 개발자는 항상 작업 사본을 태그 대신 라이브러리 트렁크로 가리키고 일부 개발 지점을 가리키고 코드를 사용할 수 있습니다 (BRRR이 필요한 경우에도 작동). 스위치는 로컬 편집 일 뿐이므로 커밋 된 코드에 영향을 미치지 않습니다. 프로젝트 개발이 불안정한 지점에 있다면 분기가 재 통합 될 때까지 외부 참조를 변경하여 스위치를 더 영구적으로 만들 수 있지만, 이것은 명백한 이유없이 일반적으로 수행되는 것이 아닙니다.
그리고 마지막으로, 프로젝트를 분기 및 태그하는 것은 주요 프로젝트의 지점이나 태그를 만드는 간단한 사례가됩니다. 그게 전부입니다. 분기 도서관에 대해 걱정할 필요가 없습니다. 그들은 스스로를 돌 봅니다. 도서관을 변경하는 과정은 프로젝트가 트렁크, 개발 지점 또는 유지 보수 릴리스인지 여부에 관계없이 변경되지 않습니다. 또한 라이브러리는 자체적으로 여러 지원 버전뿐만 아니라 여러 지원 버전 등과 독립적으로 개발 지점을 가질 수 있습니다.
트렁크 또는 개발 지점에서 외부를 사용하면 필요한 구조로 작업 영역을 구축하는 단일 체크 아웃을 가질 수 있습니다. 모든 라이브러리가 기본 루트 아래에 있으므로 빌드에서 충돌하지 않고 여러 버전의 여러 체크 아웃을 가질 수 있습니다.
나는이 시스템이 꽤 잘 작동한다는 것을 알았고, 이런 식으로 작동하지 않는 곳으로 일자리를 옮긴 후에는 이전의 작업 방식을 고정시키는 것을 발견했습니다. 라이브러리에 따라 라이브러리와 관련하여 라이브러리와 재귀적인 외부가 있는지 여부와 관련이있는 문제가 있습니다. 제가 생각하는 것은 문제가 발생하지 않는 한 (또는 과도한 통증), 프로젝트가 직접 사용하지 않더라도 특정 '깊은'종속성에 대해 알아야하는 '탈퇴'모델로 이동하는 것입니다. 또한, 외부 정의를 어디에두고이를 고수 할 위치를 결정하십시오. 다른 프로젝트의 임의의 폴더의 SVN : 외부 특성을 사냥하는 것보다 더 성가신 것은 없습니다. 트렁크의 뿌리에 두는 것은 괜찮습니다.
이것은 좋은 치프 솔루션이없는 어려운 문제입니다. 하이 엔드 솔루션은“소프트웨어 제품 라인”관리 시스템 (예 : 순수 :: 변형). 그러나 우리 대부분은 소스 코드 제어 시스템에 맞지 않습니다.
그러므로 나는 함께 갈 것입니다 LAYOUTA - 각 라이브러리 버전으로 개별적으로. 그러나 나는“트렁크" 아래에 "가지”그것은 지점이고 나는 상단에서 같은 거리에 모든 지점을 갖는 것을 좋아합니다.
다음 단계는 당신의 빌드 시스템에 따라 다릅니다. 여기에서 Visual Studio를 가정합니다.
- 각 제품 지점 트리의 근본
- 사용하려는 각 라이브러리의 지점의 이름을 포함하는 환경 변수를 정의하는 BAT 파일 작성
- 이러한 환경 변수를 사용하여 라이브러리를 참조하기 위해 Visual Studio Project 파일 편집
- Visual Studio를 시작하기 전에 Visual Studio 명령 프롬프트에서 배치 파일을 실행하십시오.
배치 파일을 사용하여 사용자 정의 MSBuild 파일을 작성하는 것을 볼 수도 있습니다. 또는 라이브러리 버전을 변경할 때 모든 프로젝트 파일을 편집하는 도구를 작성합니다.
1 ~ 2 개의 공유 라이브러리 만 있고 한 번에 하나의 제품에 대해서만 변경되는 경우, 현재 작업중인 프로젝트에 새로운 방법을 추가하기 위해 .EG. 각 프로젝트마다 도서관의 다른 지점을 갖는 것을 고려하고 SVN 1.5 병합 태클을 사용하여 진행중인 일을 추적합니다. (변경 사항이 안정되면 트럭으로 병합 한 다음 필요할 때 트럭에서 각 프로젝트 지점으로 합병하십시오).
(100 개의 라이브러리가 있다면 각 라이브러리의 마녀 버전을 추적해야합니다. 이는 매우 복잡해지기 시작합니다!)
나는 SVN : 외부를 좋아하지 않습니다. 로컬 PC의 파일 시스템에서 진행중인 내용이 명확하지 않기 때문입니다. 그러나 SVN : 외부는 실행 가능한 솔루션입니다.
비슷한 문제를 겪은 나는 당신의 고통을 알고 있습니다. 계층 적 구성 요소가있는 저장소의 종속성을 관리하는 것은 어려운 문제입니다.
당사의 프로젝트에는 다양한 구성 요소로 구성된 여러 제품 (고객에게 배송)이 있습니다 (많은 제품은 공유). 우리는 각 구성 요소를 자체적으로 가지고있었습니다 tags/branches/trunk 3 부작, 당신의 레이아웃 A와 매우 흡사합니다 (모든 권장 방법 이후).
우리는 사용했습니다 svn:externals 각 제품이 종속 구성 요소 (및 하위 구성 요소 등)를 지정하는 방법을 제공하고 처음에는 합리적으로 잘 작동했습니다. 그러나 결국 우리는 분기 할 때 발생하는 일, 한 제품이 특정 개정판에서 피분을 고정 해야하는 경우 구성 관리를 위해 외부를 통해 태그를 전파하는 방법 (실제로 같은 트리를 재구성 할 수 있습니다!) , 등등. 그래서 svn:externals 몇 가지 문제를 해결하지만 다른 문제를 소개합니다.
나는 이것을 관리하기 위해 몇 가지 스크립트를 작성하게되었지만 여전히 약간 복잡했습니다. 다행스럽게도 Python-Subversion 바인딩을 사용하여 Python 앱을 작성하여 속성을 조작 할 수 있으므로 종속 구성 요소를 통해 전파되는 태그 등을 수행 할 수 있습니다.
의존 모듈 의이 문제를 해결하도록 설계된 프로젝트가 있습니다. 피스톤. 정확히 이런 종류의 문제를위한 매우 멋지고 일반적인 도구처럼 보입니다. 나는 그것을 생산에 배치하지 않았지만 당시에는 우리가 필요한 대부분의 일을하는 것처럼 보였습니다. 그리고 그것은 확실히 외부가 제공하는 것보다 더 유연한 솔루션처럼 보입니다 (여전히 수동 프로세스입니다).
결론 : 레이아웃 A를 고수하고 피스톤을 사용하여 종속성을 관리하여 작업 디렉토리에서 모든 올바른 버전을 조립할 수 있습니다.
