모든 개발자가 알아야 할 기본적인 명확한 개념은 무엇입니까?
모든 개발자가 알아야 할 Clearcase 버전 제어 시스템의 핵심 개념은 무엇입니까?
핵심 개념?
중앙 집중식 (-복제) VCS : ClearCase는 중앙 집중식 VCS 세계 (하나 또는 여러 "중앙 집중식"저장소 또는 VOBS-버전 개체 기반-모든 개발자가 커밋에 액세스해야 함)와 분산 VCS 세계 사이의 중간에 있습니다.
그러나 "복제 된"모드를 지원하여 먼 사이트 (MultiSite ClearCase)에서 저장소를 복제하고 델타를 전송하고 소유권을 관리 할 수 있습니다. (첨부 된 라이센스 비용은 상당히 가파 릅니다.)
이것은 병렬 동시 진화를 허용하지 않기 때문에 진정한 "분산 형"모델이 아닙니다 . 브랜치는 하나의 VOB 또는 다른 VOB에서 마스터됩니다. 모든 복제본의 모든 분기에 대한 읽기 전용 액세스 권한이 있지만 마스터 VOB에서 마스터 된 분기에 대해서만 마스터 VOB에 체크인 할 수 있습니다.선형 버전 저장소 : 각 파일 및 디렉토리 에는 선형 기록이 있습니다. DAG VCS ( Directed Acyclic Graph ) 처럼 파일의 히스토리가 커밋에 연결된 디렉토리 중 하나에 링크되는 것과 같이 그들 사이에는 직접적인 관계가 없습니다 .
그것의 의미는- 두 개의 커밋을 비교할 때 모든 파일과 디렉토리의 목록을 비교하여 델타를 찾아야합니다. 커밋은 파일이나 디렉토리에서 원 자성이 아니기 때문에 모든 파일과 디렉토리를 구성하는 모든 변경 사항에 대해 단일 이름이 없습니다. 논리적 델타.
이는 또한 병합 이 기록 탐색을 통해 공통 기본 기여자 (항상 공통 조상과 동일하지는 않음)를 찾아야 함을 의미 합니다 (다음 요점 참조).
(Git은 해당 스펙트럼의 반대쪽 끝에 있으며 분산화되고 DAG 지향적입니다.
- 그래프의 노드가 다른 커밋의 노드와 동일한 "id"를 갖는 경우 더 이상 탐색 할 필요가 없습니다. 모든 하위 그래프가 동일하다는 것이 보장됩니다.
- 두 분기의 병합은 실제로 DAG에서 두 노드의 콘텐츠를 병합하는 것입니다. 재귀적이고 공통 조상을 찾는 데 매우 빠름)
3 방향 병합 : 두 버전을 병합하려면 ClearCase가 선형 기록에서 공통 기반 기여자를 찾아야합니다. 이는 복잡한 버전 트리 (분기 / 하위 분기 / 하위 하위 / 분기, ...)의 경우 상당히 길 수 있습니다. 기본 ClearCase merge 명령은 파일 또는 디렉토리를 병합하지만 재귀 적이지는 않습니다. 단일 파일 또는 파일이없는 단일 디렉토리에만 영향을줍니다 (
ct findmerge재귀적임).파일 중심 (다른 최근의 VCS 더 많은 저장소 중심) : 이는 커밋이 "수정 된 파일 집합"이 아니라 파일 단위임을 의미합니다. 트랜잭션은 파일 수준에 있습니다. 여러 파일의 커밋은 원 자성이 아닙니다.
(거의 모든 최신 도구는 원자 커밋 트랜잭션을 사용하는 "저장소 중심"이지만 RCS, SCCS, CVS 및 대부분의 다른 구형 시스템과 같은 1 세대 시스템에는 해당 기능이 없습니다.)id-managed : 각 파일과 디렉토리에는 고유 한 ID가 있습니다. 즉, 이름을 마음대로 바꿀 수 있습니다. ID가 "요소"에 남아 있기 때문에 기록이 변경되지 않습니다. 또한 디렉토리는 기록에서 파일의 추가 / 억제를 감지합니다. 파일이 "제거"(
rmname)되면이를 알지 못합니다. 디렉토리 만 알림을 받고 파일을 포함하지 않는 하위 요소 목록과 함께 새 버전을 생성합니다.
(동일한 크기와 내용을 가진 두 개의 파일을 생성하면 Git에 동일한 ID (SHA1 키)가 부여되고 Git 저장소에 한 번만 저장됩니다. ClearCase
에는 그렇지 않습니다. 경로와 이름은 두 개의 다른 분기에서 생성되며 ID가 다르면 두 파일이 병합되지 않음을 의미합니다. " 악한 쌍둥이 "라고합니다.)
브랜치는 일류 시민입니다 . 대부분의 VCS는 브랜치와 태그를 동일하게 간주합니다. 새로운 선형 히스토리가 성장할 수있는 (분기) 또는 설명이 첨부 된 (태그) 히스토리의 단일 지점입니다.
ClearCase에서는 그렇지 않습니다. 여기서 분기는 버전 번호를 참조하는 방법입니다. 모든 버전 번호는 0 (ClearCase에서 참조)에서 1, 2, 3 등으로 시작합니다. 각 분기에는 새 버전 번호 목록 (0, 1, 2, 3 다시)이 포함될 수 있습니다.
이것은 버전 번호가 고유하고 항상 증가하는 다른 시스템 (예 : SVN의 개정판) 또는 고유 한 시스템 (예 : Git의 SHA1 키)과 다릅니다.path-accessed : 특정 버전의 파일 / 디렉토리에 액세스하려면 확장 경로 (브랜치 및 버전으로 구성됨)를 알아야합니다. 이를 "확장 경로 이름":이라고합니다
myFile@@/main/subBranch/Version.
(Git은 id-SHA1 기반-: 버전 [또는 커밋], 트리 [또는 디렉토리 버전] 및 blob [또는 파일 버전, 또는 파일 내용 ]을 통해 모든 것을 참조합니다. "id-accessed"또는 "id-referenced"입니다.
ClearCase의 경우 id는 "요소"(버전에 관계없이 디렉토리 또는 파일)를 나타냅니다.)
비관적 잠금 및 낙관적 잠금 모두 : (ClearCase의 예약 또는 예약되지 않은 체크 아웃) : 비관적 잠금 (예약 된 체크 아웃)조차도 다른 사용자가 해당 파일을 체크 아웃 할 수 있기 때문에 ( "예약되지 않은 모드"임에도 불구하고) 진정한 비관적 잠금이 아닙니다. 변경하지만 첫 번째 사용자가 파일을 커밋 (체크인)하거나 요청을 취소 할 때까지 기다려야합니다. 그런 다음 동일한 파일의 체크 아웃 버전을 병합합니다.
(참고 : "예약 된"체크 아웃은 잠금을 해제하고 소유자 또는 관리자에 의해 예약 해제 될 수 있습니다.)저렴한 분기 : 분기는 모든 파일의 복사본을 트리거하지 않습니다. 실제로 아무것도 트리거하지 않습니다. 체크 아웃하지 않은 파일은 원래 브랜치에 유지됩니다. 수정 된 파일 만 선언 된 분기에 새 버전이 저장됩니다.
플랫 파일 저장 : VOB는 간단한 파일과 함께 독점 형식으로 저장됩니다. 이것은 쉬운 쿼리 언어가있는 데이터베이스가 아닙니다.
로컬 또는 네트워크 작업 공간 액세스 :
- 로컬 작업 공간은 하드 드라이브에 대한 체크 아웃을 통해 이루어집니다 (스냅 샷보기의 "업데이트").
- 네트워크 작업 공간은 동적보기를 통해 네트워크 (로컬 복사, 인스턴트 액세스 없음) 및 로컬 파일 (체크 아웃 된 파일 또는 개인 파일)을 통한 버전 파일 및 디렉토리 액세스를 결합합니다. 원거리 (버전 지정) 파일과 로컬 (개인) 파일의 조합을 통해 동적보기가 클래식 하드 드라이브처럼 표시 될 수 있습니다 (실제로 "작성된"파일은 연관된보기 저장소에 저장 됨).
중앙 추방 된 저장소 : [보기] 저장소는 일부 데이터를 보관하고 중앙 참조와의 일부 또는 모든 통신을 방지하기위한 것입니다.
작업 공간은 다음을 가질 수 있습니다.- 분산 된 저장소 :
.svn모든 곳 의 하위 디렉터리 처럼 - 중앙 집중식 저장소 : ClearCase의보기 저장소처럼보기에 표시되는 파일에 대한 정보를 포함하며 해당 저장소는보기에 대해 고유합니다.
- 추방 된 저장소 : 저장소는보기 / 작업 공간 자체의 일부가 아니지만 컴퓨터의 다른 위치 또는 LAN / WAN 외부에있을 수 있습니다.
- 분산 된 저장소 :
(Git에는 그 자체로 "스토리지"가 없습니다. .git실제로 모든 저장소입니다!)
- 메타 데이터 지향 : 모든 "키-값"은 파일이나 디렉토리에 첨부 될 수 있지만 해당 데이터 쌍은 자체적으로 기록되지 않습니다. 값이 변경되면 이전 값을 재정의합니다.
(메커니즘이 실제로 SVN의 "속성"시스템보다 약하다는 것을 의미하며, 속성은 히스토리를 가질 수 있습니다.
다른 쪽 Git는 메타 데이터에 너무 열중하지 않습니다)
- 시스템 기반 보호 : 파일 / 디렉토리 또는 저장소와 관련된 소유자 및 권한은 기본 시스템의 권한 관리를 기반으로합니다. ClearCase에는 적용 가능한 계정이 없으며 사용자 그룹은 Windows 또는 Unix 기존 그룹을 직접 기반으로합니다 (Windows 클라이언트 및 Unix VOB 서버를 사용하는 이기종 환경에서는 매우 어렵습니다!)
(SVN은 Apache 서버가 첫 번째 수준의 보호를받을 수있는 "서버 기반"보호와 비슷하지만 더 세밀한 권한을 가지려면 후크로 완료해야합니다.
Git는 직접적인 권한 관리가 없으며 후크로 제어되어야합니다. 리포지토리 간 푸시 또는 풀 중)
사용 가능한 후크 : 모든 ClearCase 작업은 트리거라고하는 후크의 대상이 될 수 있습니다. 사전 또는 사후 작업 일 수 있습니다.
CLI 관리 : cleartool은 모든 작업을 수행 할 수있는 명령 줄 인터페이스입니다.
ClearCase는 사용할 수있는 야수입니다. 느리고 버그가 많고 비싸다. CC 사용에 대처하기 위해 수행 한 작업은 다음과 같습니다.
- 체크인 할 때 항상 좋은 댓글을 남겨주세요.
- 공통 구성 사양을 사용하고 자주 변경하지 마십시오.
- VPN이나 느린 네트워크 연결을 통해 CC를 사용하지 마십시오.
- 시작시 CC Doctor 로딩을 끕니다.
- 다른 디렉토리로 파일을 이동하지 마십시오.
- 체크인을 위해 파일 당 최소 2 분을 예약하십시오.
- 스냅 샷보기는 느리지 만 동적보기는 더 느립니다.
- 예약 된 파일과 병합이 고통스럽기 때문에 조기에 자주 체크인하는 개발 습관을 만드십시오.
- 모든 개발자가 기본적으로 예약되지 않은 파일을 체크 아웃하도록합니다.
우리는 지금까지 15 년 넘게 CC를 사용해 왔습니다. 좋은 기능이 많이 있습니다.
우리의 모든 개발은 지점에서 이루어집니다. 저는 오늘 몇 가지 변경 사항을 위해 몇 가지를 만들었습니다. 브랜치에 체크인했을 때 동료가 변경 사항을 검토 한 다음 작업이 필요한 곳인 / main / LATEST로 다시 병합되었습니다. 브랜치에서 이전 릴리스를 사용했다면 더 어렵지 않았을 것입니다.
The merges from my temporary branches were fully automatic; no-one had changed the files I worked on while I had them checked out. Although by default checkouts are reserved (locked), you can always unreserve the checkout later, or create the checkout unreserved. When the changes take multiple days, the resynchronization of my temporary branch with the main branch is easy and usually automatic. The mergetool is OK; the biggest problem for me is that my server machine is 1800 miles or so from my office (or home), so that X over that distant is a bit slow (but not intolerably so). I've not used a better mergetool, but that may not be saying much since I've not used any other graphical mergetool.
뷰 (동적 뷰)는 설정에서 빠릅니다. 스냅 샷보기를 사용하지 않았지만 내가 도울 수있을 때 Windows에서 작업하지 않습니다 (우리 팀은 Windows에서 스냅 샷보기를 사용합니다. 이유는 확실하지 않습니다). 복잡한 분기 시스템이 있지만 주요 개발은 / main / LATEST에서 수행되고 릴리스 작업은 분기에서 수행됩니다. GA 후 유지 관리 작업은 릴리스 특정 분기에서 수행되고 / main / LATEST (모든 중간 버전을 통해)로 병합됩니다.
CC는 훌륭한 관리자를 필요로합니다. 우리는 그들을 보유하고 있으며 그렇게하는 데 행운이 있습니다.
CC는 사용하기가 쉽지 않지만 현재로서는 CC를 사용하지 않은 사람들에게 'git'이 위협적이라고 생각합니다. 그러나 기본 사항은 체크 아웃, 변경, 체크인, 병합, 분기 등 거의 동일합니다. 디렉토리는 분기 될 수 있으며-신중하게-확실히 버전 제어됩니다. 그것은 매우 귀중합니다.
사무실이 CC에서 언제든 전환되지 않습니다.
포함 된 버전 번호-좋은가요 나쁜가요?
나는 썼다 :
CC에서 가장 큰 문제는 소스 파일에 버전 번호를 포함하지 않는다는 것입니다. 자식도 AFAICT가 가지고있는 문제입니다. 나는 그 이유를 반쯤 알 수있다. 그래도 추적 가능성을 포기하는 것을 좋아하지 않습니다. 그래서 저는 여전히 대부분의 개인 작업에 RCS (CVS도 아님)를 사용합니다. 언젠가는 git로 전환 할 수 있습니다. 그러나 그것은 충격이 될 것이고 (SCCS 및) RCS를 중심으로 구성된 릴리스 시스템을 재구성하는 데 많은 작업이 필요할 것입니다.
이에 대해 @VonC는 다음과 같이 말합니다.
우리는 항상 그 관행을 악 (메타 데이터 정보를 데이터로 혼합)으로 간주하여 "지옥 병합"을 도입했습니다. Java 파일 내에서 Clearcase 파일 버전을 가져 오는 방법 도 참조하십시오 . 물론 적절한 병합 관리자 를 사용하는 경우 RCS 키워드 대체 ( Clearcase Manual : Checkin Trigger Example )에 트리거 를 사용할 수 있습니다 .
이 토론에서 드러난 몇 가지 문제가 있으며 모두 함께 섞여 있습니다. 내 견해는 구식에 가깝지만 그 뒤에 근거가 있으며 시간을내어 기록 할 것입니다.
배경
1984 년에 RCS가 출시 될 무렵 (1983 년)에 SCCS를 배웠지 만 SCCS는 내 컴퓨터에 있었고 인터넷은 기껏해야 초기 단계였습니다. 저는 90 년대 중반에 SCCS에서 RCS로 옮겼습니다. SCCS 날짜 형식은 수년 동안 두 자릿수를 사용하고 SCCS가 보편적으로 시간에 고정되는지 여부가 분명하지 않았기 때문입니다. 어떤면에서는 SCCS만큼 RCS를 좋아하지 않지만 좋은 점이 있습니다. 상업적으로 제 고용주는 1995 년 중반까지 SCCS를 사용했지만 1994 년 초부터 Atria ClearCase로 전환하여 한 번에 하나씩 별도의 제품 세트를 다루기 시작했습니다.
트리거를 사용한 초기 ClearCase 실험-지옥 병합
우리 프로젝트는 나중에 CC에 대한 경험이 있었을 때 마이그레이션되었습니다. 부분적으로 내가 주장했기 때문에 체크인 트리거를 통해 소스 파일에 버전 제어 정보를 삽입했습니다. 이것은 VonC가 말했듯이 병합 지옥으로 이어지기 때문에 잠시 동안 지속되었습니다. 문제는 태그가 / main / branch1 / N 인 버전이 공통 기본 버전 / main / B에서 / main / M과 병합되는 경우 파일의 추출 된 버전에 각 버전에서 편집 된 단일 행이 포함된다는 것입니다. 갈등. 그리고 그 충돌은 자동으로 처리되지 않고 수동으로 해결되어야합니다.
이제 SCCS에는 ID 키워드가 있습니다. ID 키워드는 편집중인 파일과 편집되지 않는 파일의 두 가지 형식을 사용합니다.
Edit Non-Edit
%I% 9.13
%E% 06/03/09
%Z% @(#)
%M% s.stderr.c
편집 가능한 SCCS 파일 버전 (% x % 표기법 사용)의 3 방향 병합을 시도한 경우 해당 행에서 메타 데이터를 변경하지 않는 한 (예 : US-에서 변경) 메타 데이터가 포함 된 행에서 충돌이 발생하지 않습니다. 스타일 % D % 날짜를 영국 스타일 % E % 날짜로-SCCS는 ISO 스타일 2009-03-15 날짜를 표준으로 지원하지 않습니다.)
RCS는 또한 키워드 메커니즘을 가지고 있으며 키워드는 두 가지 형식을 취합니다. 하나는 아직 RCS에 삽입되지 않은 파일 용이고 다른 하나는 다음을 가진 파일 용입니다.
Original After insertion
$Revision$ $Revision: 9.13 $
$Date$ $Date: 2009/03/06 06:52:26 $
$RCSfile$ $RCSfile: stderr.c,v $
차이점은 키워드 뒤의 '$'와 ':', 공백, 텍스트, 공백 및 마지막으로 '$'사이입니다. 키워드 정보로 무엇을하는지 확인하기 위해 RCS와의 병합을 충분히 수행하지 않았지만 확장 된 표기법과 '축약 된'표기법을 모두 동일하게 취급하면 (확장 된 자료의 내용에 관계없이) 병합 할 수 있습니다. 충돌없이 발생하여 병합 출력에 계약 된 표기법이 남습니다. 이는 체크인 후 결과 파일을 검색 할 때 적절하게 확장됩니다.
ClearCase 문제는 적절한 병합 관리자가 없다는 것입니다.
SCCS 및 RCS에 대한 논의에서 언급했듯이 3 방향 병합이 올바른 (계약되거나 편집 가능한) 형식으로 키워드를 처리하면 병합 충돌이 없습니다.
CC의 문제점 (이 관점에서 볼 때 CC의 구현 자들은 동의하지 않음)은 키워드 처리 시스템이 없기 때문에 적절한 병합 관리자가 없다는 것입니다.
키워드를 처리하는 시스템과 적절한 병합 관리자가 있다면 :
- 시스템은 메타 데이터를 적절한 마커의 파일에 자동으로 포함합니다.
- 병합시 시스템은 마커가 다르게 변경되지 않는 한 메타 데이터 마커가있는 라인이 충돌하지 않는다는 것을 인식합니다. 메타 데이터 콘텐츠를 무시합니다.
단점은 메타 데이터 마커를 인식하고 특별히 처리하는 특별한 차이 도구가 필요하거나 차이 도구에 제공된 파일이 정규화되어야한다는 것입니다 (메타 데이터 마커가 중립 형식으로 축소됨-$ Keyword $ 또는 RCS 및 SCCS 용어로 % K %). 저는이 약간의 추가 작업이 지원되지 않는 이유라고 확신합니다. 제가 항상 느꼈던 것이 그러한 강력한 시스템에서 근시안적이라고 느꼈습니다. 나는 RCS 또는 SCCS 표기법에 특별한 첨부 파일이 없습니다. SCCS 표기법은 어떤면에서는 다루기가 더 쉽지만 본질적으로 동등합니다. 그리고 동등한 표기법을 사용할 수 있습니다.
여전히 파일의 메타 데이터가 좋다고 생각하는 이유
I like to have the metadata in the source code because my source code (as opposed to my employer's source code) is distributed outside the aegis of the source code control system. That is, it is mostly open source - I make it available to all and sundry. If someone reports a problem in a file, especially in a file they've modified, I think it is helpful to know where they started from, and that's represented by the original metadata in the source file.
Here, SCCS has an advantage over RCS: the expanded forms of the SCCS keywords are indistinguishable from regular text, whereas the RCS keywords continue to look like keywords, so if the other person has imported the material into their own RCS repository, their metadata replaces my metadata, a problem that does not happen with SCCS in the same way (the other person has to do work to overwrite the metadata).
Consequently, even if someone takes a chunk of my source code and modifies it, there are usually labels enough in it to identify where it came from, rather than leaving me to speculate about which version it is based on. And that, in turn, makes it easier to see what parts of the problem are of my making, and what parts are of their making.
Now, in practice, the way open source works, people don't migrate code around as much as you might think. They tend to stick with the released version fairly closely, simply because deviating is too expensive when the next official release is made.
I'm not sure how you are supposed to determine the base version of a piece of source code that originated from your work and has been revised since then. Finding the correct version, though, seems key to doing that, and if there are fingerprints in the code, then it can be easier.
So, that's a moderate summary of why I like to embed the version information in the source files. It is in large part historical - SCCS and RCS both did it, and I liked the fact that they did. It may be ancient relic, something to be bidden farewell in the era of DVCS. But I'm not yet wholly convinced by that. However, it might take still more of an essay to explain the ins and outs of my release management mechanism to see why I do things as I do.
One aspect of the reasoning is that key files, such as 'stderr.c' and 'stderr.h', are used by essentially all my programs. When I release a program that uses it, I simply ensure I have the most recent version - unless there's been an interface change that requires a back-version. I haven't had that problem for a while now (I did a systematic renaming in 2003; that caused some transitional headaches, but Perl scripts allowed me to implement the renaming pretty easily). I don't know how many programs use that code - somewhere between 100 and 200 would be a fair guess. This year's set of changes (the version 9.x series) are still somewhat speculative; I haven't finally decided whether to keep them. They are also internal to the implementation and do not affect the external interface, so I don't have to make up my mind just yet. I'm not sure how to handle that using git. I don't want to build the library code into a library that must be installed before you can build my software - that's too onerous for my clients. So, each program will continue to be distributed with a copy of the library code (a different sort of onerous), but only the library code that the program needs, not the whole library. And I pick and choose for each program which library functions are used. So, I would not be exporting a whole sub-tree; indeed, the commit that covered the last changes in the library code is typically completely unrelated to the commit that covered the last changes in the program. I'm not even sure whether git should use one repository for the library and another for the programs that use it, or a common larger repository. And I won't be migrating to git until I do understand this.
OK - enough wittering. What I have works for me; it isn't necessarily for everyone. It does not make extraordinary demands on the VCS - but it does require version metadata embedded in the files, and CC and Git and (I think) SVN have issues with that. It probably means I'm the one with problems - hangups for the lost past. But I value what the past has to offer. (I can get away with it because most of my code is not branched. I'm not sure how much difference branching would make.)
Eric's Source Control HOWTO is a great guide that is Tool-Independent.
I worked with clearcase for the better part of 6 years and generally found it tolerable. It does have a certain learning curve but once you get used to the quirks you can pretty much work smoothly with it. A very competent CC admin that knows what he's doing is essential for anything but trivial setups. Unless you have one, people are going to run into problems and soon enough there will be talk about the "ClearCase" problem. Then management will have to intervene by switching to something else causing only waste of time for everyone involved. CC is not a bad product, It's just sometimes poorly understood.
Here are few concepts I found important, some of these are not entierly CC only oriented -
- A check-out is unlike the regular CVS-like notion of a check-out. When you check out you lock the file until you check-in it in.
- There is no problem with moving files. infact this works flawlessly.
- Version trees are essential to understanding what has been happening to a file. They can get quite messy for active files but when you get used to watching them it becomes a very useful tool and One that is very lacking in other source control tools such as SVN (to some extent).
- Do not use dynamic views under any circumstances. its not worth it.
- before making a new branch, stream or project, advise with your admin to make sure that what you create is really what will serve you best. When starting a new code-base, make sure you get the streams and projects layout right from the start by planning ahead. changing it later is a real head-ache if even possible.
- Fine tune the privileges of users and set up triggers for common events to prevent common mistakes or enforce policies. The server is very configurable and most for problems you encounter there is probably a reasonable solution.
- educate the developers on anything from basic concepts to advance operations. A power-user that can find what the problem is using cleartool lowers the load on the admin.
- Don't leave dangling streams and views. When a developer leaves the project have someone to remove all the views he had on his machine and delete all his private streams. Not keeping your server clean will result in... it being dirty and over time, slow. When you do a "find all checkouts" on all streams and views you should not see files that are checked-out by people who no longer exist.
- Mandate an "always rebase before deliver" policy for child branches to avoid people "breaking the integration stream" when delivering code that conflicts with recent changes.
- Continuous integration - don't let the integration stream stagnate while each developer or team work on their own branch. Mandate once every X time everyone has to atleast rebase to the most recent integration baseline if not to deliver their stable changes. This is indeed very difficult to do, especially with large projects but the other alternative is "integration hell" where at the end of the month no one does anything for 3 days while some poor sod tries to make all the changes fit together
How to use git on top of ClearCase!
- Git Backstage, Under the Covers and on the Down Low
- ClearCase Globally, Git Locally
- A Clearcase for Git, git-cc bridge
In my opinion, branching and merging are the most important concepts in any source control system (next to versioning itself, of course).
Once you understand how that's done (and Clearcase does it very well, to the point where we do even small changes as a branch and re-merge, not something I would have ever done with RCS or CVS), you'll find your life is made a lot easier.
Somehow off-topic, but - I don't know almost no developer who's happy with ClearCase. I was told it should have sophisticated features, but as a svn and git user I cannot possibly think of something I miss in git or subversion. So that's something one should know about ClearCase - most developers are really happy to work with something simple as subversion or git (yes, even git is easier to grasp), And even after I knew how to complete the simplest tasks in ClearCase, I had the constant feeling ClearCase works against me, not with me.
I've worked on a number of medium to large projects successfully using both Clearcase and SVN. Both are great tools but the team using them need documented processes. Create a process that describes how you will use the version control system.
1) find or create a best practices document for your Version Control System. Here's one for subversion, adapt it to your Clearcase process. All developers must adhere to the same game plan.
Basically decide if you are going to 'always branch' or 'never branch'.
Never Branch Scheme:
- The never branch scheme is what SourceSafe uses where files are locked during checkout and become available during checkin. This scheme and is okay for small (1 or 2 developers) team projects.
Always Branch Scheme:
- The always branch scheme means developers create branches for each bugfix or feature add. This scheme is needed for larger projects, projects that have a lead (buildmeister) who manages what changes get allowed into /main/LATEST in Clearcase or /trunk in SVN.
- The always branch scheme means you can checkin often w/o fear of breaking the build. Your only opportunity to break the build is only after your bugfix or feature is complete and you merge it to /main/LATEST.
'Branch when needed' is a compromise and may work best for many projects.
2) With Clearcase (and Subversion) you must learn to merge -- merging is your friend. Learn to use the merging capabilities of Clearcase or use a tool like Beyond Compare or emacs-diff. If your project is well modularized (many small decoupled files), you will benefit with fewer (or no) conflicts during merging.
3) Enjoy.
If you are using ClearCase, make sure you use the UCM that comes with it and Composite Components.
It makes all of your branching/merging effortless. I am talking about major re-org branches that run for 6 months involving tens of thousands of changes include directory renaming, file renaming, etc that automatically resolve 99.9% of the deltas.
Also, we only use SnapShot views, not dynamic views. Our snapshot views load faster than you can drag and drop (Windows) the same source tree from a network drive.
The only gripe I have about UCM is that history cannot span components. If you split up a component into multiple new components, each new component starts at /main/0.
How do you implement the version control tools on your project depends on your project size and scope and team earlier experience. ClearCase is fantastic tool for larger projects interms of developers and size of the project. Managing the branch is one of the very important prospect while using version control tool. without branching and merging it is cake walk during your project lifecycle. But you cant stay away with merging why because it is allows you to lock and fantastic parallel development.
There is a very handy command cleardescribe that is useful many times. Can be used to get the details of labels and branches. The syntax is:
cleardescribe lbtype:<LABELNAME>@\<VOB-NAME>
cleardescribe brtype:<BRANCHNAME>@\<VOB-NAME>
Specifically, this lets you know the label was applied on which branch and which branch is the parent branch to a branch-in-question.
'developer tip' 카테고리의 다른 글
| Express.js-헤더가 이미 전송되었는지 확인하는 방법은 무엇입니까? (0) | 2020.11.16 |
|---|---|
| Lodash를 Angular JS와 함께 사용하는 방법은 무엇입니까? (0) | 2020.11.16 |
| jQuery의 keydown () 이벤트 핸들러에서 누른 문자를 디코딩하는 방법 (0) | 2020.11.16 |
| gradle의 versionNameSuffix에 날짜 빌드를 추가하는 방법 (0) | 2020.11.16 |
| 프록시 뒤의 dockerfile에서`apt-get`을 어떻게 실행합니까? (0) | 2020.11.16 |