svn post-commit 후크 : "오류 해결 사례"& "skipped \\ ip-address \ users \ myDir" "메시지

Question

Windows에 Collabnet SVN 서버가 설치되어 있습니다. 작업 복사본 "A"에서 저장소에 커밋 할 때 프로젝트의 작업 복사본 "B"를 업데이트해야합니다. 작업 복사본 "B"는 네트워크 드라이브 [H -> \\ ip-address \ users \ myDirB] : 내 포스트 커밋 후크에, 아래의 코드 줄을 지정하고 커밋 지금

• 복사 "A"를 작동 변경은 세트 :

SET WORKING_COPY=H:/myDirB

나는 오류 : 사용자가 지정한 또는 경우

• 를 "오류 해결하는 경우": SVN 후크를 후 커밋

  : SET WORKING_COPY=//ip-address/users/myDirB

나는 오류 "skipped \ ip-address \ users \ myDirB" "

무엇입니까? 내가 잘못하고있어? 건배.

주의 사항 : * 오래된 Collabnet Subversion 서버 내 C에 설치되어 있습니다 : 그것은 내가 통해 자동으로 업데이트 할 네트워크 디렉토리에 대한 모든 권한을 가진 서비스 계정으로 실행중인

• 드라이브 훅을 후 커밋 즉, - \\ IP 주소의 \ 사용자 \ myDirB *

• 나는 또한 IP 주소의 \ 사용자가 myDirB가 H에 매핑 \ \\ 경로를 가지고 : 드라이브

Answer 1

cmd.exe에 일반 경로 (드라이브 문자, 콜론, 상대 경로)가 필요하므로

은 작동하지 않습니다. UNC 나 IP 주소와 같은 다른 경로는 처리 할 수 ​​없습니다. 드라이브 문자가 있어야합니다.

SET WORKING_COPY=H:/myDirB

그러나 로그인 한 사용자로 H :를 매핑했기 때문에이 방법은 작동하지 않습니다. 그러나 hook 스크립트는 svn 서버가 실행중인 사용자, 즉 서비스 계정으로 실행 중입니다. 그리고 서비스 계정은 이 아니고은 H: 드라이브가 매핑됩니다.

Answer 2

이렇게하려면 게시 커밋 훅을 사용하지 말 것을 권장합니다. 당신이 알아내는 것처럼 그것은 영원히 부서지기 쉽고 복잡 할 것입니다.

svn repo를 모니터링하고 필요한 경우 코드를 배포하는 연속 통합 빌드를 설정해야합니다. 이러한 우려를 분리하면 장래에 두통을 피할 수 있고 팀 (메신저, 이메일 또는 대시 보드)에 알릴 수있는 쉬운 방법을 제공하며 자동화 된 테스트를 원할 경우 언제든지 도움이 될 것입니다.

Answer 3

두 가지 문제는 (1) 경로 및 (2) 권한이었습니다. 우리의 오래된 설정에는 Windows 2008 R2의 collabnet subversion server 1.5.6과 apache 2.2가 포함되어 있습니다 (Windows 2008 R2에서는 wandisco 1.7.2/apache2.2입니다).

처음에는 매핑 된 드라이브의 경로와 로컬 시스템 계정으로 실행되는 Subversion 및 Apache 서비스가있었습니다. 그래서, 우리는 같은 것을했다 :

SET WORKING_COPY=X:\the\path\to\theworkingcopy 

CLI를 통해 그것을 잘 된 실행하지만, 커밋 이후 후크를 통해 실행 그래서

Error resolving case of 'X:\the\path\to\theworkingcopy' 

같은 로그 메시지의 결과를, 나는 UNC 경로를 사용 WORKING_COPY 변경 같은 :

\\servername\DRIVELETTER$\the\path\to\theworkingcopy 

여전히 같은 문제,하지만 난 네트워크 권한으로 실행하는 데 필요한 (모두) 서비스를 생각, 그래서 서비스가 SVN 자체에 대한 도메인 계정에 "다른 이름으로 로그온"변경 rver 및 아파치.

다른 하나의 문제는 서비스의 "사용자로 로그온"사용자를위한 도메인을 설정하는 것이 었습니다. 도메인 사용자를 사용했지만 도메인에 와일드 카드를 사용했습니다. ". \ theuser"

그러면 효과가 있습니다.

이것이 취성있는 해결책 인 경우, 저는 CI가 더 좋은 방법이라는 데 동의합니다. UNC를 통한 svn 업데이트가 (1) 문서화되어 있고 (2) 현재 작동하고 있으며 (3) 가까운 미래에 변경 될 가능성은 거의 없지만 (KBB에서 언급했듯이) 우려를 분리하지는 않습니다.