이제 모든 Plastic SCM 서버에서 Git 프로토콜(git 및 http 지원)을 사용하여 리포지토리를 제공할 수 있습니다.
즉, 모든 Git 클라이언트가 Plastic SCM 서버에 직접 내보내거나 가져올 수 있습니다.
이제 기본 Git 기능을 사용하여 Git 에코시스템의 모든 툴을 Plastic SCM에 직접 연결할 수 있습니다. Plastic을 사용하는 팀은 이제 Git용으로 개발된 모든 DevOps, CI, 프로젝트 관리 통합을 활용할 수 있습니다.
GitServer는 GitSync의 서버와 같은 것으로 모든 Plastic SCM 클라이언트가 git 서버로 내보내거나 가져올 수 있으며, Git 상호 운용성 루프를 닫습니다.
다양한 시나리오에서 GitServer를 사용할 수 있지만, GitServer의 주요 목적은 모든 Git 소프트웨어를 Plastic에 연결하기 위한 "범용 연결자" 역할을 하는 것입니다.
모든 Git 호환 git 클라이언트는 GitServer로 변경사항을 내보내고 가져올 수 있어 다양한 시나리오에서 활용할 수 있습니다.
Plastic SCM 서버에서 GitServer를 매우 간단하게 활성화할 수 있습니다.
plasticd.exe가 있는 위치)에서 빈 파일 gitserver.conf를 생성합니다.
이제 다음과 같이 Git에서 Plastic SCM으로 내보내기/가져오기를 할 수 있습니다.
git push --all git://localhost/default이 명령은 default라는 Plastic 리포지토리로 git 리포지토리를 내보냅니다.
gitserver.conf는 GitServer 구성을 제어하는 파일이며, 다음과 같은 형식을 사용합니다. 여기서 각 줄은 선택사항입니다.
# port configuration tcp.port=9418 http.port=80 # mapping storage - the mappings between git and plastic objects # the default path is automatically generated by the server storage.baseDirectory=e:\gitserver\mappings # mapping interval - how often GitServer looks for new changes # on the Plastic side to make them available to git # By default, it is 5 minutes (300 seconds) mapping.interval=300 # repositories to be exported. By default, all repositories # will be available on GitServer unless a list is specified here export.repo=code export.repo=quake export.repo=robotcode
Windows는 HTTP에 보안 제한을 적용하므로 GitServer가 지정된 HTTP 포트를 사용할 수 있도록 특별한 조치를 취해야 합니다. 이 조치는 권한을 가진 계정에 의해 실행되지 않는 프로세스에만 영향을 미칩니다. 따라서 Plastic SCM을 Windows 서비스로 실행하면 http를 활성화하기 위한 특별한 조치가 필요하지 않습니다.
Plastic SCM 서버가 비 관리자 모드로 실행되는 경우(기본 Windows 서비스로 실행되지 않는 경우) 프로세스를 실행하는 특정 사용자에게 권한을 부여하기만 하면 됩니다. 이 작업은 다음 명령을 통해 처리됩니다.
> netsh http add urlacl url=http://+:80/ user=DOMAIN\userGitServer는 HTTP 기본 인증을 사용하여 Git 클라이언트를 보호할 수 있습니다.
즉, Git 클라이언트는 GitServer에 연결할 때 이 인증이 활성화되어 있는 경우, 사용자 이름과 비밀번호를 입력하라고 요청합니다.
HTTP 인증을 구성하려면 gitserver.conf 파일에 다음 항목을 추가하면 됩니다.
# http authentication http.basicauth=true
물론 HTTP 프로토콜에서 수신하도록 GitServer를 구성해야 합니다.
# http authentication http.port=8080 http.basicauth=true
Plastic SCM 서버는 Git 클라이언트가 투명하게 액세스하는 Git 서버처럼 동작할 수 있습니다.
변경사항은 다음과 같은 여러 소스에서 GitServer로 올 수 있습니다.
git push 작업을 사용합니다. Git 명령이 완료되면 변경사항을 Plastic SCM과 Git 클라이언트에서 즉시 확인할 수 있습니다.check-in 또는 replica 작업을 사용합니다. 이러한 변경사항은 Git 클라이언트에서 즉시 확인할 수 없습니다. 백그라운드 스레드가 mapping.interval 간격(초)마다 Git으로 "익스포트된" 리포지토리에 새 Plastic 변경사항이 있는지 검사합니다. 변경사항이 발견되면 매핑을 계산하고 이 작업이 완료되면 새 변경사항을 Git에서 확인할 수 있습니다.Plastic SCM은 Git에 매핑될 수 없는 기능인 부분 복제본을 지원합니다. 순수 Plastic 환경에서는 매우 유용한 기능이지만 Git/Plastic 혼합 시나리오에서는 문제가 될 수 있습니다.
다음과 같은 시나리오를 고려해 보십시오. John은 우선 주 브랜치를 주 리포지토리(GitServer를 사용하여 Git와 동기화된 리포지토리)로 내보내지만, 주 브랜치에 병합이 있는 브랜치 main/task001은 내보내지 않습니다.
GitServer 코드가 새 체인지 세트(이 예에서는 숫자 10)를 Git에서 사용할 수 있도록 "인덱싱"을 시작하면 체인지 세트 10만 표시됩니다. 새 체인지 세트는 Git 커밋으로 사용 가능하며 Git 클라이언트에서 가져올 수 있습니다.
나중에 John이 main/task001을 중앙으로 내보낸다고 가정해 보겠습니다. 체인지 세트 10이 이미 익스포트됐고 task001을 다시 계산하면 10의 "sha"가 변경되어 전에 이미 10을 가져온 원격 git 리포지토리와의 동기화가 단절되므로 새 브랜치 task001은 Git에 표시되지 않습니다.
이러한 제한 사항을 이해하고 Git과 동기화되어야 하는 Plastic 리포지토리에 적절한 브랜치가 있을 때만 git 매핑이 계산되도록 해야 합니다.
다음 시나리오에서 중앙 리포지토리는 부분 본제본을 사용하여 방금 task002를 수신했습니다. task002의 부모를 주 리포지토리에서 사용할 수 없으므로 Git에 대한 매핑이 계산되면 부모 브랜치는 무시됩니다.
나중에 task001을 내보낸 경우에도, task001을 중앙 리포지토리로 내보내기 전에 매핑을 계산한 경우 task002는 계속해서 Git 리포지토리에 표기되지 않습니다.
Git에서는 이미 원격으로 내보낸 리포지토리에서 "베이스를 재설정"하거나 "내역을 재작성"하지 않도록 강하게 권장한다는 점에 유의하십시오. 여기에서 설명하는 시나리오도 마찬가지입니다. 새 내역을 고려한다는 것은 Git에서 내역을 다시 작성하여 원격 Git 리포지토리를 손상시키는 것을 의미합니다.
이제, 병합 시 연결되지 않은 브랜치가 완전히 복제되었던 이전 예를 변형하여 가정하겠습니다.
이 경우 task002는 연결되지 않은 브랜치이므로 Git에 표시될 수 없습니다. 이는 내역이 손상될 수 있으므로 새 체인지 세트 10도 Git에 표시되지 않음을 의미합니다. 브랜치 task002의 부모가 복제되면 GitServer에서 전체 내역을 연결하고 체인지 세트 10이 Git 클라이언트에 표시될 수 있습니다.
일부 체인지 세트가 조건을 충족하지 않더라도 강제로 GitServer가 Git에서 하나의 브랜치를 사용하도록 할 수 있습니다.
이전 시나리오에서는 task002가 완전히 연결되지 않고 Git에 매핑되지 않더라도 GitServer가 체인지 세트 10을 강제로 "매핑"할 수 있었습니다.
다음과 같이 add branch.toForceMap 항목을 gitserver.conf에 추가하기만 하면 됩니다.
# branches which changesets are made visible # although they have unlinked merge sources branch.toForceMap=/main
미해결 Xlink가 있는 체인지 세트도 GitServer에서 무시되므로 Git 클라이언트에서 미해결 Xlink를 볼 수 없습니다.
main@root 브랜치에 main@xlink에 대한 Xlink가 있는 다음 시나리오를 고려해 보겠습니다. root의 체인지 세트 15에서 Xlink는 Xlink의 체인지 세트 4를 가리키지만, 이 체인지 세트는 아직 복제되지 않았습니다.
즉, 체인지 세트 15는 무시되고 Xlink가 있는 체인지 세트가 복제될 때까지 Git 클라이언트에 해당 체인지 세트가 표시되지 않습니다.
일부 내용이 손실되더라도 Git과 동기화하도록 하기 위해, 누락된 Xlink를 건너뛰도록 GitServer를 구성할 수 있습니다.
다음과 같이 unresolvedxlink.skip=true를 gitserver.conf에 추가하기만 하면 됩니다.
# skip the xlink entries that cannot be resolved unresolvedxlink.skip=true
Git 하위 모듈은 Plastic SCM Xlink로 변환됩니다. Xlink는 말하자면 개발자의 편의를 위해 발전된 하위 모듈과 같습니다.
GitServer로 일부 git 변경사항/리포지토리를 내보낼 때, GitServer가 해결 방법을 모르는 git 리포지토리를 가리키는 하위 모듈이 존재한다면 작업이 실패할 수 있습니다.
>git push --all git://localhost/default Counting objects: 143, done. Writing objects: 100% (143/143), 106.43 KiB | 0 bytes/s, done. Total 143 (delta 0), reused 143 (delta 0) error: invalid ref status from remote: The specified repository couldn't be found: mduem. To git://localhost/default ! [remote failure] master -> master (remote failed to report status) error: failed to push some refs to 'git://localhost/default'이러한 경우에 존재하는 하위 모듈은 GitServer에서 유효한 Plastic SCM 리포지토리로 판단하지 않는 mduem이라는 리포지토리를 가리킵니다.
mduem이라는 리포지토리를 Plastic에 생성해야만 이 문제를 해결할 수 있으며, 그러면 하위 모듈 리포지토리가 GitServer로 내보내집니다.
>cm repository create mduem >git clone https://github.com/user/mduem.git Cloning into 'mduem'... remote: Counting objects: 461, done. Receiving objects: 95% (438/461) Receiving objects: 100% (461/461), 68.40 KiB | 0 bytes/s, done. Resolving deltas: 100% (172/172), done. Checking connectivity... done. >git push --all git://localhost/mduem Writing objects: 100% (453/453), 731.45 KiB | 0 bytes/s, done. Total 453 (delta 0), reused 453 (delta 0) To git://localhost/mduem * [new branch] master -> master >git push --all git://localhost/default Counting objects: 118, done. Writing objects: 100% (118/118), 83.75 KiB | 0 bytes/s, done. Total 118 (delta 0), reused 118 (delta 0) To git://localhost/default 46232e0..41c12e1 master -> master이 경우 Git 하위 모듈 정의는 다음과 같습니다.
[submodule "mduem"]
path = mduem
url = git://github.com/user/mduem
Git 하위 모듈과 Plastic Xlink 간 매핑을 커스터마이즈한다고 가정해 보겠습니다.
다음 항목을 gitserver.conf 파일에 추가하여 이 작업을 처리할 수 있습니다(여러 Git 하위 모듈에 필요한 만큼 추가 가능).
repository.mapping=git://github.com/user/mduem -> mduem-xlinked@localhost:8084 writable:true relativeserver:false
즉, mduem 리포지토리는 Plastic 측에서 mduen-xlinked로 변환됩니다.
Git 하위 모듈에 Plastic SCM 리포지토리에 매핑되지 않도록 Git 하위 모듈을 건너뛸 수 있습니다. 하위 모듈을 건너뛰려면 gitserver.conf를 다음과 같이 편집합니다.
# when a submoule points to one of the following # git urls, it will be ignored. ignore.submoduleUrl= git://github.com/user/mduem
필요한 만큼 ignore.submoduleUrl 항목을 추가할 수 있습니다.
Plastic SCM 서버가 성공적으로 GitServer를 활성화하려면 유효한 Enterprise Edition 라이센스가 필요합니다.
Personal Edition 및 Community Edition은 GitServer를 지원하지 않습니다.
지원되는 모든 Plastic SCM 서버 플랫폼(Linux, Windows, macOS)에서 GitServer를 사용할 수 있습니다.
GitServer로 내보내지는 Git 리포지토리에서 가속화, 베이스 재설정, 삭제 커밋을 사용하지 마십시오.
베이스 재설정 또는 삭제 커밋을 수행해서는 안 된다는 방침은 이미 일반 git 서버에 내보낼 git 간에 적용되는 제한 사항입니다.
Plastic SCM과 Git 간의 내부적인 차이점으로 인한 가속화 제한 사항이 있습니다. Git에서 단일 커밋은 둘 이상의 브랜치 헤드로 가리킬 수 있으므로 단일 커밋이 둘 이상의 브랜치에 있을 수 있습니다.
Plastic SCM에서 모든 체인지 세트는 단일 브랜치에 연결되며 둘 이상의 브랜치에 동시에 있을 수 없습니다. 그러므로 Plastic SCM과 동기화될 수 있도록 Git 리포지토리에서 병합 가속화를 사용하지 않는 것이 좋습니다.
GitServer는 익스포트한 리포지토리에 대한 보안 검사를 수행하지 않습니다.
Git 클라이언트는 전체 리포지토리 콘텐츠를 다운로드하거나 리포지토리에 변경사항을 푸시할 수 있습니다.
gitserver.conf에 있는 export.repo 항목을 사용하여 GitServer에 표시되는 리포지토리를 제한할 수 있습니다.
GitServer는 델타화된 Git 패키지를 지원하지 않습니다. 따라서 패키지는 델타화되지 않은 형식으로 전송되어야 합니다.
이는 두 시스템 간의 메타데이터 및 데이터 변환 속도를 높이기 위한 성능 제한 사항입니다.
Git 측에서 델타화를 비활성화하려면 git 리포지토리에서 다음 명령을 실행합니다.
git config --global pack.window 0GitServer가 내보내는 중에 델타가 포함된 팩을 수신하면 다음 오류 메시지가 표시됩니다.
git deltas are not supported. Please, set the 'pack.window 0' config variable or run an 'git repack -a -f -d' command이 메시지에는 git 리포지토리를 다시 패키징하여 델타를 비활성화하는 명확한 지침이 나와 있습니다.
git repack -a -f -dGitServer는 단순 클론을 지원하지 않습니다. Git 클라이언트 버전에 따라 다음 오류 메시지가 표시됩니다.
> git clone git://localhost/default --depth=1 Cloning into 's'... fatal: Server does not support shallow clientsgit 클라이언트 버전 1.7.2부터 어떤 호환성 문제도 발견되지 않았습니다. 하지만 가급적 최신 git 클라이언트 소프트웨어를 사용하는 것이 좋습니다.
git 내보내기는 객체가 Plastic SCM에 임포트되는 동안 진행도를 보여 주지 않습니다. 이 과정은 내보내기 크기에 따라 몇 초, 몇 분 또는 몇 시간이 소요될 수 있습니다.
여러 수준을 가지는 브랜치 이름은 Plastic SCM과 Git에서 다를 수 있습니다.
예를 들어 Plastic SCM 브랜치 /main/Fix-5.0/scm003은 Git에서 main-Fix-5.0-scm003으로 변환됩니다.
현재 GitServer는 git:// 및 http:// 프로토콜을 통해 액세스할 수 있습니다.
SSH 지원은 나중에 추가될 예정입니다.
현재 GitServer에서 익스포트된 리포지토리의 파일 내용이 중복되어 있습니다. 즉, 데이터베이스 내부와 GitServer 스토리지 폴더에 파일이 Plastic SCM 형식으로 저장되어 있습니다.
어떠한 이유에서든 GitServer 매핑 폴더를 다시 만들어야 하는 경우, 새 Git SHA와 기존 Git SHA의 일치를 보장할 수 없습니다.
다음은 기존 Git SHA와 일치하지 않는 새 Git SHA를 생성하는 작업의 예입니다.
따라서, Git 매핑이 다시 생성된 후에는 반드시 새 git 리포지토리를 생성하고 Plastic에서 복제해야 합니다.
이전 git 리포지토리를 다시 사용하면 커밋이 중복되고, Plastic으로 다시 내보낼 때 체인지 세트도 결국 중복됩니다.