설치 프로그램이 꽤 좋아 보입니다. 나는 1.0.0 릴리스와 함께 변경 세트를 기반으로 새로운 long-term named branch을 만들 것이다. development on the default branch을 유지하고 각 릴리스에 대한 분기를 만듭니다. 여기
나는 왼쪽 위 변경 집합 아래의 POM의 버전 번호 및 지점명 모든 방법을 쓰기 :
는
1.0.0-SNAPSHOT 1.0.0 1.1.0-SNAPSHOT
default: o --- o --- o --- o ------ o --- o --- o --- o --- o --- o
\ /
1.0.x: o --- o --- o --- o -------- o --- o --- o
1.0.1-SNAPSHOT 1.0.1 1.0.2-SNAPSHOT
그래서 당신은 default를 사용하여 버전 1.0.0-SNAPSHOT에 즐겁게 작업 분기. 릴리즈가 끝나면 플러그인은 1.0.0으로 변경 집합을 만들고 즉시 default 브랜치에 1.1.0-SNAPSHOT으로 다른 변경 집합을 만듭니다.
지금 또는 나중에 1.0.x 릴리스에서 분기 할 수 있습니다. 상관 없습니다. 당신의 분기를 수행 할 때
$ hg update 1.0.0 # <- this is a tag
$ hg branch 1.0.x
# edit the POM to change version to 1.0.1-SNAPSHOT
$ hg commit -m "Started 1.0.x branch"
이제 개발자들은 항상 지점에 대한 최신 변경 집합에 도착
$ hg update 1.0.x # <- this is a branch
을 사용할 수 있으며, hg update default을 다시 개발의 주요 라인에 얻을. 변경 집합이 1.0.x 지점에 최선을 다하고 있습니다 때 버그도 해결 될 수 있도록, 당신은 default에 다시 병합 할 수 있습니다 :
은 서버에 하나 개 또는 두 개의 저장소 사이의 선택은 주로 관련이없는
$ hg update default
$ hg merge 1.0.x
$ hg commit -m "Merge in bugfix-123 from 1.0.x"
입니다 지금 명명 된 브랜치를 사용하여 안정된 변경 집합 (이들은 1.0.x에 있음)과 덜 안정적인 변경 집합 (이들은 default에 있음)을 구별합니다. 그러나 안정적인 릴리스마다 서버에 저장소를 유지하는 것이 좋습니다.Jenkins에서 작업을 설정하거나 cronjobs를 사용하여 클론이 최신 상태로 유지되도록 정기적 인 간격으로
등의 작업을 수행 할 수 있습니다.
[hooks]
changegroup.1.0.x = hg push --branch 1.0.x ../foo-1.0.x
changegroup.1.1.x = hg push --branch 1.1.x ../foo-1.1.x
개발자는 후크가 완료 될 때까지 기다려야 할 것이다, 그러나 당신은 단지 지역 저장소 사이에 밀어 때 신속해야한다 : 당신은 또한 다음과 같은 주요 dev에 환매 특약의 일부 changegroup 후크를 만들 수 있습니다. 이 문제가 발생하면 비동기 동기화 메커니즘 (Jenkins, cronjob, ...)을 사용하십시오.
