git svn이 반드시 Git의 HTTP 프록시를 쓰는 것은 아니다

git fetch 은 성공하지만 git svn fetch 은 서버에 도달하지 못합니다. 명령 접두사가 같아도 후자의 작업은 다른 클라이언트 스택을 통해 Subversion 저장소와 통신합니다.

Git 고유의 http.proxy 항목이 그 Subversion 연결을 설정한다고 가정하지 마세요. git svn이 실행되는 환경에서 Subversion 라이브러리가 사용하는 런타임 설정을 찾아야 합니다.

Subversion의 servers 설정에는 다음이 들어갈 수 있습니다:

[global]
http-proxy-host = proxy.example
http-proxy-port = 8080

호스트 이름과 포트는 별개의 값입니다. HTTP 프록시 목록은 허용된 공용 Subversion 경로의 후보를 제공합니다. 프록시 계정 항목은 저장소 자격 증명과 별개입니다. Subversion 서버 그룹 설정은 호스트 이름과 일치하며 임의의 저장소 경로와 일치하지 않습니다. 이를 Subversion의 인터페이스로 보아야 하며, Git 프록시 URL의 다른 표기로 보면 안 됩니다.

Windows에서는 경로가 의외의 복병일 수 있다

네이티브 Subversion 실행 파일과 git svn 설치가 서로 다른 환경과 서로 다른 홈 디렉터리 해석을 사용할 수 있습니다. svn.exe 가 사용하는 설정을 편집했다고 해서 git svn 호출이 그것을 읽었다는 증거는 아닙니다.

어떤 실행 파일과 라이브러리 환경이 관여하는지 기록한 뒤, 그 실제 설정 위치를 확인하세요. 한 사용자의 경로를 시스템 전체 스크립트에 복사하지 마세요.

계정은 따로 관리하세요

프록시가 외부 연결을 인증할 수 있습니다. 그 뒤 Subversion 저장소가 다른 계정을 요구할 수 있습니다. HTTP 407 과 저장소 권한 오류는 서로 다른 단계를 나타냅니다.

정책이 URL이나 경로를 거부하면 승인된 엔드포인트와 접근 방식을 사용하세요. 브라우저로 저장소의 웹 인터페이스를 여는 것은 부분적인 비교일 뿐입니다. 다른 계정, 설정 저장소, 경로를 쓸 수 있기 때문입니다. 목표는 의도한 중개자를 통한 Subversion 작업의 성공이며, 단순히 평범한 웹 페이지 요청이 성공하는 것이 아닙니다.