SVN을위한 버전 관리 전략

9

24 시간 내내 회사의 버전 관리 전략을 시도 할 것입니다. 우리는 현재 SVN을 사용하고 있지만 구조는 없습니다. 기본적으로 트렁크 만 있고 커밋 만합니다. 최근 개발 관리자는 "태그"역할을하는 두 번째 리포지토리를 시작했지만 동일한 리포지토리의 일부가 아니라 완전히 분리 된 리포지토리이므로 "트렁크"와 수동으로 병합해야합니다. 실제로 "Dev"라는 폴더가 하나만 있습니다 (실제로 다른 날짜에 다른 "Dev"폴더가 있지만 "Dev"가 기본 폴더 임). 그 아래에는 다른 모든 항목이 있습니다. 다른 모든 프로젝트. 프로젝트별로 구성되지 않았으며 브랜치 / 태그 / 트렁크 또는 기타 개념이 없습니다. 처음에 설정 한 사람 물론) SVN을 설정하는 방법을 전혀 모르는 것처럼 보였으므로 그 이후로 누군가가 무언가를 깨뜨리는 것을 두려워하여 올바르게 행동하는 법을 배우지 않았습니다. 우리는 어떤 종류의 CI (또는 불행히도 자동화 된 테스트)를 사용하지 않습니다.

먼저 프로젝트별로 분리해야합니까? 예를 들면 다음과 같습니다. 두 개의 ASP.NET 웹 사이트 (웹 응용 프로그램, 웹 사이트가 아님), 웹 서비스, 모든 테이블 스크립트 및 저장 프로 시저를위한 배포 폴더, 외부 프로젝트를위한 두 개의 명령 줄 클라이언트 WebSites 및 공통 비즈니스 오브젝트 등이있는 공유 폴더. 이들 각각이 브랜치 / 태그 / 트렁크 설정이있는 자체 프로젝트이거나 다음과 같아야합니다.

dev/
  branches/
  tags/
  trunk/
      Site1/
      Site2/
      WebService/
      SharedCode/

모든 가지와 모든 Dev 폴더의 사본을 가지고 있습니까? 공유 코드 라이브러리와 웹 사이트 중 하나 이상 (보통 둘 다)을 변경해야하는 경우가 종종 있기 때문에 이러한 접근 방식은 삼키기가 더 쉬울 수 있습니다.

둘째, 우리는 dev 서버와 라이브 서버에 정기적으로 릴리스 (우리의 말로 "푸시")를 수행합니다. 내가 처리하는 가장 좋은 방법은 모든 개발이 트렁크로 들어가고 분기는 "임시적"이며 트렁크에 영향을 줄 수있는 새로운 기능을 추가하는 데 사용되고 태그는 릴리스 용이라는 것입니다. 그래서, 우리는 매달 말하고 새로운 모듈을 연구하고 있습니다. 트렁크를 분기하고 해당 분기를 내 코드, 쓰기 및 테스트에 사용합니다. 모듈이 완료되면 다시 트렁크로 병합하고 분기를 삭제하고 배포 할 준비가되면 태그를 지정합니다 ( "May2011"). 버그 수정이 게시 된 후 May2011 태그에서 수정되어 트렁크로 병합됩니다 (따라서 트렁크도 수정 사항을 얻습니다). 그리고 2011 년 5 월 수정으로 다시 밀려 날까요? 이것이 태깅의 의도입니까?

version-control svn

— 웨인 몰리나
소스

5

박스 전략 외부 : git로 전환하십시오.

— Rein Henrichs

그것이 옵션이라면, 나는 그것을 할 것입니다 (또는 우리는 Windows 상점이기 때문에 Mercurial). 적어도 SVN으로 적절한 환경을 설정하려고 시도하는 것보다 완전히 새로운 소스 제어 시스템으로 이동하려고 할 때 더 많은 저항에 직면 할 것이라고 생각합니다.

— 웨인 몰리나

2

DVCS에 관심이 있지만 Subversion은 좋은 도구입니다. CVS 또는 폴더 버전 관리가없는 다른 솔루션은 더 나쁩니다.

— Matthew Rodatus

2

@ Wayne M-당신은 그것이 실제로 다른 길을 찾을 수 있습니다. DVCS 사용의 이점을 모두 얻는다면 사람들이보다 합리적인 환경 구조에 가입하게하는 것이 더 쉬울 수 있습니다. 전환으로 gitsvn 또는 hgsubversion을 사용하여 저렴한 로컬 분기 / 리포지토리 액세스를 시도하도록 peopel을 얻는 것이 좋습니다. 일단 도구에 연결되고 사용되면 기본 리포지토리를 위해 DVCS로 이동하려는 그룹 전체의 요구가있을 수 있습니다.

— Mark Booth

5

통합 빌드 프로세스를 원할 경우 다음과 같이 분기 / 태그 / 트렁크를 루트에 배치하십시오.

branches/
tags/
trunk/
  dev/
    ...

통합 빌드 프로세스가 필요하지 않은 경우 원하는 경우 각 프로젝트 내에 분기 / 태그 / 트렁크를 넣을 수 있습니다. 그러나 각 프로젝트 내에 배치 한 후 통합 빌드로 마이그레이션하기 어려울 수 있습니다. 통합 빌드는 프로젝트간에 공유 구성 요소를 게시 할 필요가없는 것과 같은 장점이 있습니다. 모두 빌드의 일부입니다.

개인적으로 저는 통합 된 빌드 프로세스를 좋아합니다. 또한 "dev"프로젝트가 있어야한다고 생각하지 않습니다. 트렁크 바로 아래에 프로젝트가 있어야하고 트렁크를 dev 분기로 분기해야합니다. 릴리스에 태그를 사용하십시오. 예를 들어 다음과 같이하십시오.

branches/
  dev/
    Site1/
    Site2/
    WebService/
    SharedCode/
tags/
  release1/
    Site1/
    Site2/
    WebService/
    SharedCode/
trunk/
  Site1/
  Site2/
  WebService/
  SharedCode/

— 매튜 로다 투스
소스

1

통합 빌드는 프로젝트간에 공유 구성 요소를 게시 할 필요가없는 것과 같은 장점이 있습니다. 모두 빌드의 일부입니다.

— Matthew Rodatus

2

여러 개의 통합 빌드가 필요한 경우 각각에 대해 트렁크 아래에 디렉토리를 작성하십시오. 그러나 나는 하나의 "dev"라는 이름을 짓지 않을 것이다. 예를 들어, 장치 드라이버에서 작동하는 회사 조직과 회사 웹 사이트에서 작동하는 조직의 두 가지 주요 개발 조직이있을 수 있습니다. 아마도 두 개의 개별 통합 빌드를 원할 것입니다.

— Matthew Rodatus

1

svn 내의 코드 구조에 관한 한 이것은 실제로 개인적인 선택입니다.

프로젝트가 관련되거나 코드를 공유하는 경우 공통 트렁크를 원한다고 제안합니다. 독립적 인 경우 별도의 트렁크 또는 별도의 리포지토리를 원합니다. 프로젝트에 대한 svn 히스토리 사본을 써드 파티에 제공해야하는 경우 별도의 저장소에 있으면 훨씬 쉽습니다.

따라서 귀하의 경우 공유 코드가 있고 분기 / 태그에 해당 공유 코드를 포함시키려는 경우 위에서 스케치 한 레이아웃이 합리적이라고 들립니다.

태그 및 브랜치 사용에 대한 설명은 눈에 띄게 들리며 svn이 사용될 것으로 예상되는 방법입니다. 그것은 실제로 내가 이해하는 태그의 의도입니다. svn 태그와 브랜치의 BTW는 실제로는 동일하지만 적용한 용어가 적용됩니다.

개인적으로 트렁크에 커밋 된 것은 빌드해야하고, 원자 적이어야하며, 단위 테스트를 중단해서는 안된다는 경고를 추가 할 것입니다. 지사는 미완성 된 작업을위한 것입니다. 트렁크는 언제라도 잠재적 인 릴리스 후보가 될 것으로 기대합니다.

— 루크 그레이엄
소스

테스트를 거친 프로덕션 준비 코드 만 트렁크에 있어야한다고 말씀하십니까? 커밋 된 코드는 테스트를 빌드하고 통과해야하며 트렁크 코드는 물론 테스트를 통과해야한다고 생각합니다. 그러나 SVN의 목적은 개발 히스토리를 따를 수있는 것으로 보이며 여러 분기로 분할되지 않으면 더 쉽습니다. 트렁크가 테스트되고 생산 준비 상태에있을 때 트렁크를 병합하는 분기가 있어야합니까?

— Mr. Jefferson

0

다음은 Subversion 저장소를 배치하는 가장 좋은 방법입니다

project_a
     - branches
     - tags
     - trunk
project_b
     - branches
     - tags
     - trunk
project_c
     - branches
     - tags
     - trunk
master
     - branches
     - tags
     - trunk       
         - svn:external project_a
         - svn:external project_b
         - svn:external project_c

이 방법으로 개별 프로젝트를 스스로 확인할 수 있습니다.

3 개의 프로젝트를 모두 체크 아웃하고 모 놀리 식 빌드 스크립트 / 시스템으로 통합 빌드를 수행하려면 svn : externals가 있는 다른 모든 프로젝트를 마스터에 매핑 하는 마스터 모듈을 사용하여 조사 하십시오 . trunk

언뜻보기에는 더 복잡하지만 Subversion 으로이 문제를 해결하는 가장 유지 관리 가능하고 관용적 인 방법입니다.

2

나는 매우 동의하지 않습니다. 저장소는 코드를 저장하는 것 이상을 수행합니다. 조직 구조와 구성 요소 간의 관계를 전달합니다. 암시 적이지만 중요한 통신 채널입니다. 각 프로젝트를 개별적으로 분리하면 의사 소통에 인공적이고 불필요한 장벽이 생깁니다.

— William Payne