TortoiseSVN을 업그레이드할 때, 기존 버전을 먼저 제거해야 하나요?

아니요. 새 버전을 기존 버전 위에 바로 설치할 수 있습니다. 설치 프로그램이 자동으로 이전 버전을 먼저 제거합니다. 하지만 설치 프로그램이 완료된 후 컴퓨터를 재부팅해야 합니다! 아니면 최소한 로그오프했다가 다시 로그인해야 합니다.

TortoiseSVN을 설치하려면 관리자 권한이 필요한가요?

예, TortoiseSVN을 설치하려면 관리자 권한이 필요하거나, 최소한 관리자 권한으로 설치할 수 있는 권한이 있어야 합니다.

하지만 TortoiseSVN이 설치된 후에는 관리자 권한 없이 사용할 수 있습니다.

TortoiseSVN을 사용하기 전에 Subversion을 설치해야 하나요?

아니요. TortoiseSVN은 저장소에 액세스하는 데 필요한 모든 것을 포함하고 있습니다. 서버를 설정하려는 경우에만 Subversion 패키지가 필요합니다.

TortoiseSVN을 어떻게 제거하나요?

Windows 제어판의 프로그램 추가/제거에서 단순히 제거하면 됩니다. 이는 저장소나 작업 사본에 전혀 영향을 미치지 않습니다.

제 컴퓨터에서 MSI 설치가 비활성화되어 있습니다. .exe 설치 프로그램이 있나요?

.exe 설치 파일은 도움이 되지 않을 것입니다. MSI 설치가 컴퓨터에서 실제로 비활성화되어 있다면, 관리자 권한도 없을 것입니다. 그리고 TortoiseSVN을 설치하려면 그 권한이 필요합니다 (셸 확장 기능은 설치를 위해 관리자 권한이 필요합니다). 하지만 먼저 MSI 설치가 실제로 비활성화되어 있는지 확인하십시오. 이는 도메인 관리자가 비활성화한 경우에만 가능합니다.

왜 .exe 대신 MSI를 사용하거나 전혀 설치 프로그램을 사용하지 않나요?

다른 것 대신 MSI를 설치 프로그램으로 사용하는 데에는 여러 가지 이유가 있습니다

• 개방적입니다. Orca와 같은 MSI 도구를 사용하여 모든 사람이 우리가 무엇을 하는지 볼 수 있습니다.
• 필요에 따라 기존 MSI를 쉽게 조정할 수 있습니다. MSI를 수동으로 편집할 수 있는 도구가 있습니다. .exe 설치 프로그램으로는 그렇게 할 수 없습니다.
• 단순히 관리자 권한이 아니라 SYSTEM 권한으로 실행됩니다. TortoiseSVN은 사용자 계정이 접근할 수 없는 레지스트리 키를 생성하고 수정해야 하는 셸 확장 기능이므로 이는 중요합니다 (UAC가 활성화된 Vista에서 특히 중요합니다).
• GPO를 통해 도메인 내 여러 컴퓨터/사용자에게 MSI를 쉽게 배포할 수 있습니다. 다른 모든 설치 프로그램은 도메인 관리자가 먼저 해당 설치 프로그램을 MSI 내에 '포장'해야 합니다.
• MSI는 Windows 애플리케이션을 설치하는 표준이자 권장 방법입니다. 이제 Microsoft로부터 "Certified for Vista" 로고를 받으려면 필수입니다.
• MSI 파일을 만드는 훌륭한 오픈 소스 도구가 있습니다: 저희가 사용하는 WiX입니다.
• MSI는 설치된 모듈의 참조 카운팅을 관리하여 소위 DLL 지옥을 방지합니다.
• TortoiseSVN을 셸에 등록해야 하므로 설치 프로그램이 필요합니다. 간단한 실행 파일은 작동하지 않을 것입니다.

설치 프로그램이 오류 메시지와 함께 중단됩니다

설치가 성공하지 못하는 몇 가지 이유가 있습니다

• "이 설치 패키지는 이 프로세서 유형에서 지원되지 않습니다. 제품 공급업체에 문의하십시오." 이는 일반 32비트 운영 체제에 64비트 버전의 TortoiseSVN을 설치하려고 시도하고 있음을 의미합니다. OS에 맞는 올바른 MSI 파일을 다운로드하여 사용해야 합니다. 일반 32비트 OS의 경우, MSI 파일에 x64가 없는지 확인하십시오.
• "TortoiseSVN을 설치하기 전에 설치 프로그램이 중단되었습니다. 다시 시도하려면 설치 프로그램을 다시 시작해야 합니다." 이는 설치 프로그램 MSI가 있는 폴더에서 SYSTEM 사용자에게 읽기/실행 권한이 없음을 의미합니다. MSI 파일을 다른 위치로 이동하거나 SYSTEM 사용자에게 읽기 및 실행 권한을 부여하십시오.
• "Windows 설치 관리자 서비스에 액세스할 수 없습니다." 이는 안전 모드에서 Windows를 실행 중이거나 Windows 설치 관리자가 제대로 설치되지 않은 경우 발생할 수 있습니다. 기본적으로 MSI가 저장된 폴더가 암호화되거나 압축되지 않았는지 확인하십시오.
• "시스템에서 지정된 파일의 장치를 열 수 없습니다.", 보통 이어서 "설치 프로그램이 이 패키지를 설치하는 동안 예기치 않은 오류가 발생했습니다. 이는 이 패키지의 문제일 수 있습니다. 오류 코드 2755"가 나옵니다. 이 오류는 다음과 같은 경우에 발생할 수 있습니다.
  • 설치 프로그램이 임시 디렉터리에 액세스할 수 없거나, 컴퓨터의 기본 임시 디렉터리가 깨끗하지 않거나, 설치를 실행할 충분한 공간이 없는 경우.
  • 매핑된 네트워크 드라이브를 통해 터미널 서버에서 설치가 실행되는 경우.
  • Windows NT 시스템 환경에서 설치 프로그램이 Installer 디렉터리를 생성하거나 쓸 수 없는 경우.
  • 임시 폴더 및/또는 MSI 파일이 암호화/압축된 경우
  이 문제를 해결하려면 임시 폴더를 비우고, 설치 프로그램 MSI 파일을 SYSTEM 사용자가 완전한 액세스 권한을 가진 로컬 하드 드라이브로 이동하십시오.
• "이 설치 패키지는 Windows Installer 서비스에 의해 설치될 수 없습니다. Windows Installer 서비스의 최신 버전이 포함된 Windows 서비스 팩을 설치해야 합니다. 최소한 MSI 설치 관리자 버전 3이 필요합니다.

설치 후, TortoiseSVN이 나타나지 않고, 컨텍스트 메뉴를 사용할 수 없습니다

XP 또는 Vista 64비트를 사용 중이라면 TortoiseSVN의 x64 버전을 설치했는지 확인하십시오. 해당 OS 버전의 탐색기는 64비트 애플리케이션이므로 32비트 버전의 TortoiseSVN을 로드할 수 없습니다.

하지만 해당 OS 버전에서도 32비트 버전의 TortoiseSVN을 계속 설치할 수 있습니다. 이는 해당 애플리케이션의 32비트 파일 열기/저장 대화 상자에 나타날 것입니다.

설치 후, 파일에 대한 TortoiseSVN 컨텍스트 메뉴가 없습니다

이 문제는 레지스트리의 권한 설정으로 인해 발생할 수 있습니다. 다음을 시도해 보세요.

1. regedit을 사용하여 레지스트리 편집기로 이동합니다.
2. HKEY_CLASSES_ROOT/*/​shellex/ContextMenuH​andlers/TortoiseSVN을 클릭합니다.
3. 액세스가 거부되었다는 오류 메시지 상자를 확인합니다.
4. 위에서 언급한 키를 마우스 오른쪽 버튼으로 클릭하고 "사용 권한(Permissions)"으로 이동합니다...
5. 사용 권한 대화 상자에서 "고급(Advanced)"을 클릭합니다.
6. "소유자(Owner)" 탭을 클릭하고, 계정을 클릭한 다음 "적용(Apply)"을 클릭합니다.
7. 대화 상자를 확인하고 "추가(Add)..."를 클릭합니다.
8. 텍스트 영역에 계정 이름을 입력하고 "확인(OK)"을 클릭합니다.
9. 사용 권한 대화 상자를 확인합니다.
10. HKEY_CLASSES_ROOT/*/​shellex/ContextMenuH​andlers/TortoiseSVN을 클릭합니다.
11. 오류 메시지 상자가 없는지 확인합니다.

레지스트리 편집 권한이 부족하여 문제가 발생하는 경우, SysInternals PsTools Suite를 다운로드하고 다음 명령으로 regedit을 실행하여 해결할 수 있습니다.

TortoiseSVN 업그레이드 후, 모든 아이콘 오버레이가 사라졌습니다

이는 일부 업그레이드에서 알려진 문제이며, 특히 1.6.8 버전에서 보고되었습니다. 이러한 문제가 발생하면 복구 설치(및 물론 재부팅)를 시도해 보세요.

• 아이콘 오버레이가 나타나지 않는 이유는 무엇인가요?
• 오버레이 아이콘은 나타나지만, 모두 나타나는 것은 아닙니다!

아이콘 오버레이가 나타나지 않는 이유는 무엇인가요?

• 설치 후 물론 PC를 재부팅했습니까? 아직 재부팅하지 않았다면 지금 재부팅하십시오. TortoiseSVN은 Windows Explorer 셸 확장이며 Explorer와 함께 로드됩니다.
• TSVN 설정으로 이동하여 고정 드라이브에 대한 아이콘 오버레이를 활성화하십시오. 설치 프로그램은 현재 사용자에 대해 자동으로 이 작업을 수행하지만 (다른 사용자에게는 할 수 없습니다...) 설치한 사용자 이외의 다른 사용자로 TSVN을 사용하고 있으므로 수동으로 설정해야 합니다.

오버레이 아이콘은 나타나지만, 모두 나타나는 것은 아닙니다!

이 아이콘들이 모두 시스템에서 사용되지 않는다는 것을 알 수 있습니다. 이는 Windows에서 허용하는 오버레이 수가 15개로 제한되어 있기 때문입니다. Windows는 이 중 4개를 사용하고, 나머지 11개는 다른 애플리케이션에서 사용할 수 있습니다. 그리고 OneDrive가 설치되어 있다면 5개의 슬롯을 더 사용합니다. 다른 클라우드 드라이브 도구가 설치되어 있다면 이 슬롯들이 소진될 수 있습니다. TortoiseSVN은 "선량한 시민(TM)"이 되려고 노력하며 다른 앱에 기회를 주기 위해 오버레이 사용을 제한합니다.

• 일반, 수정됨 및 충돌됨은 항상 로드되고 표시됩니다 (가능한 경우!).
• 삭제됨은 가능하면 로드되지만, 슬롯이 충분하지 않으면 수정됨으로 돌아갑니다.
• 읽기 전용은 가능하면 로드되지만, 슬롯이 충분하지 않으면 일반으로 돌아갑니다.
• 잠금은 이미 13개 미만의 오버레이가 로드된 경우에만 로드됩니다. 슬롯이 충분하지 않으면 일반으로 돌아갑니다.
• 추가됨은 이미 14개 미만의 오버레이가 로드된 경우에만 로드됩니다. 슬롯이 충분하지 않으면 수정됨으로 돌아갑니다.

regedit을 사용하여 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers를 확인하여 어떤 다른 앱이 오버레이를 사용하고 있는지 확인할 수 있습니다.

• Windows 자체. Vista와 Win7은 XP보다 더 많이 사용합니다.
• OneDrive
• GDrive
• Mega
• Dropbox
• 기타 다수

너무 많은 오버레이 핸들러가 설치되어 있고 TortoiseSVN이 오버레이를 표시하지 않는 경우, 레지스트리에서 설치된 핸들러 중 일부를 삭제해 볼 수 있습니다. 하지만 레지스트리를 편집할 때는 주의하십시오!

아이콘이 로컬 드라이브에서만 보이고 네트워크 드라이브에서는 보이지 않는 이유는 무엇인가요?

설정 -> 모양 및 느낌 -> 아이콘 오버레이로 이동하여 오버레이 아이콘을 보려는 드라이브 유형을 선택하십시오. 네트워크 드라이브에 대한 오버레이를 활성화하면 TortoiseSVN뿐만 아니라 전체 시스템이 느려질 수 있다는 점에 유의하십시오.

SUBST된 드라이브의 오버레이 아이콘이 엉망인 이유는 무엇인가요?

작업 사본이 SUBST 드라이브에 있는 경우 아이콘이 섞일 수 있습니다.

이 문제는 캐시가 동시에 두 "다른" 위치의 상태를 가져오려 하지만, 실제로는 동일한 위치이므로 동일한 작업 사본에 대해 두 번의 상태 가져오기가 동시에 발생하기 때문에 발생합니다.

이를 해결하는 쉬운 방법이 있습니다: 오버레이 표시에서 원래 경로를 제외하십시오 (설정->아이콘 오버레이->경로 제외).

예를 들어, \\station\folder\wc를 g:로 매핑했다면, \\station\folder\wc*를 제외 패턴으로 입력하십시오.

오버레이가 작동하도록 하는 또 다른 방법은 "상태 캐시" 설정을 "기본값"에서 "셸"로 변경하는 것입니다.

오버레이가 잘못된 상태를 표시하는 이유는 무엇인가요?

때로는 오버레이가 파일 및/또는 폴더의 실제 상태를 반영하지 않는다는 것을 알 수 있습니다. 일반적으로 F5 키를 누르면 오버레이가 올바르게 나타나게 됩니다 (캐시가 상태를 다시 가져올 때까지 몇 초 기다려야 할 수도 있습니다).

탐색기의 왼쪽에 있는 트리 보기는 완전히 다른 문제입니다. F5 키를 아무리 눌러도 오버레이를 업데이트하지 않습니다. 이는 탐색기 자체의 문제이며 TortoiseSVN의 범위 밖입니다.

간단한 설명: 트리 보기는 네트워크 드라이브 및 기타 네임스페이스 확장을 포함하여 전체 탐색기 트리를 항상 표시합니다. 이들은 매우 느릴 수 있으므로 (예: 느린 네트워크 드라이브), 탐색기 트리는 오버레이 확장에 업데이트된 오버레이를 항상 요청하지 않습니다. 폴더가 변경되었으며 그에 따라 오버레이를 업데이트해야 한다고 탐색기에 알려도 그렇게 하지 않습니다. 먼저 폴더가 실제로 변경되었는지 자체적으로 확인하고, 폴더가 실제로 변경되었다고 생각하는 경우에만 오버레이를 업데이트합니다.

이제 폴더의 Subversion 상태는 폴더 자체와 아무 관련이 없으므로, 폴더 자체는 실제로 변경되지 않습니다 (.svn 폴더 내의 일부 파일만 변경될 뿐, 폴더 자체는 변경되지 않습니다). 따라서 탐색기는 오버레이를 업데이트하지 않습니다.

왼쪽 트리 보기에서도 탐색기가 오버레이를 새로 고치게 하는 몇 가지 요령과 해결 방법이 있지만, 이는 항상 작동하지 않는 요령과 해결 방법입니다.

보통 작동하는 한 가지 요령이 있지만, 이는 느리고 TortoiseSVN이 즉시 사용할 수 없습니다. 시스템을 너무 많이 느리게 할 것입니다. 하지만 작업 사본의 루트에서 '정리' 명령을 실행하여 수동으로 해당 요령을 트리거할 수 있습니다. 정리 명령이 완료되면 트리 보기가 오버레이 아이콘을 업데이트할 때까지 몇 초 기다려야 합니다.

오버레이 아이콘이 가끔 무작위 그래픽으로 변하는 이유는 무엇인가요?

Windows 아이콘 캐시는 상당히 버그가 많은 존재입니다. 다음 방법 중 하나로 이를 해결할 수 있습니다.

• Microsoft의 TweakUI를 설치하고 아이콘 재구축 옵션을 실행합니다.
• 또는 아이콘 캐시 크기를 늘립니다. HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer로 이동하여 Max Cached Icons라는 새 문자열 값을 추가하십시오. 기본값은 500이며, 2048로 늘려보십시오.
• 또는 Windows 디렉터리에 있는 ShellIconCache 파일을 삭제합니다. 그리고 재부팅합니다.
• TortoiseSVN 1.3.0 이상 버전에서는 TortoiseProc.exe /command:rebuildiconcache와 같이 명령줄에서 TortoiseProc을 호출하여 아이콘 캐시를 재구축할 수도 있습니다.

'업데이트 가능' 또는 '다른 사람이 잠금'에 대한 오버레이가 없는 이유는 무엇인가요?

이러한 오버레이를 표시하려면 TortoiseSVN은 오버레이가 표시될 때마다 저장소에 연결해야 합니다. 그러면 탐색기가 엄청나게 느려질 것입니다. 서버는 응답하는 데 종종 몇 초, 때로는 몇 분이 걸리기도 합니다. 버전 관리되는 폴더를 열 때마다 그런 일이 일어나는 동안 탐색기가 멈춰 있기를 정말로 원하시나요?

TortoiseSVN의 기본적인 설계 특징은 컨텍스트 메뉴 항목 중 하나에 의해 명시적으로 요청될 때를 제외하고는 저장소에 절대 연결되지 않는다는 것입니다. 이러한 제약에도 불구하고 빠른 응답을 유지하는 것은 여전히 힘든 작업입니다.

어떤 사용자가 작업 사본에 파일을 잠갔는지 또는 어떤 파일이 업데이트되어야 하는지 확인하려면 '수정 사항 확인' 대화 상자를 사용하고 '저장소 확인' 버튼을 클릭하십시오.

파일을 마우스 오른쪽 버튼으로 클릭할 때 CPU 사용량이 100%가 됩니다.

파일을 마우스 오른쪽 버튼으로 클릭할 때마다 CPU가 100%로 상승합니다 (오른쪽 클릭 메뉴가 표시되는 동안). 메뉴에서 무언가를 선택하면 CPU가 정상으로 돌아옵니다. '아무것도 없는 곳'을 마우스 오른쪽 버튼으로 클릭하면 CPU는 괜찮습니다. 무슨 일인가요?

XP에는 특정 구성에서 컨텍스트 메뉴에 액세스할 때 CPU 사용량이 100%로 치솟는 알려진 버그가 있습니다. 이 버그는 파일 복사 작업을 중단시키고, 네트워크 연결을 느리게 하며, 스트리밍 미디어(예: 오디오, 비디오)를 왜곡시킵니다. 이 버그를 해결하려면 다음 단계를 수행하여 GUI의 전환 효과를 비활성화해야 합니다.

1. 제어판 디스플레이 애플릿을 시작합니다.
2. 모양 탭을 선택합니다.
3. 효과를 클릭한 다음 "메뉴 및 도구 설명에 다음 전환 효과 사용" 확인란을 선택 취소합니다.
4. 모든 대화 상자를 닫으려면 확인을 클릭합니다.

자주 효과적인 다른 해결책은 컨텍스트 메뉴를 표시하기 위해 마우스 오른쪽 버튼을 클릭하기 전에 파일이나 폴더를 왼쪽 클릭하는 것입니다.

네트워크 디렉터리에 로컬 저장소를 만들 수 있나요?

네트워크 공유에서 저장소를 사용할 수 있지만, 로컬 하드 드라이브를 사용하듯이 단일 사용자로서만 가능합니다. 다음 FAQ 항목은 이러한 방식으로 저장소를 공유하는 것이 왜 "나쁜 생각(TM)"인지 설명합니다. 네트워크 공유에 저장소를 보관해야 할 정말 중요한 이유가 없다면 일반적으로 그렇게 하지 않는 것이 가장 좋습니다.

네트워크 공유의 저장소에 정말로 액세스해야 한다면 다음 중 하나를 수행해야 합니다.

1. 아래 구문을 사용하여 드라이브 매핑을 사용합니다.

   Map //server/shared to S

   file:///S:/repos (드라이브 문자 앞에 슬래시 3개)

2. 아래 구문을 사용하여 UNC 경로를 직접 지정합니다.

   Subversion >= 1.2

   file://server/shared/repos (슬래시 2개)

   Subversion < 1.2 (이상한 구문, 저희도 압니다)

   file://///server/shared/repos (슬래시 5개)

   file:///\server/shared/repos (슬래시 3개 + 역슬래시)

하지만 경고하지 않았다고 말하지 마십시오...

서버를 설정하는 대신 네트워크 공유에 저장소를 보관할 수 있나요?

여러 컴퓨터에서 저장소에 액세스해야 하는 경우, 이론적으로 네트워크 공유에 저장소를 생성하고 file:// 프로토콜을 사용하여 액세스할 수 있습니다. 실제로는 다음과 같은 네 가지 매우 중요한 이유로 권장되지 않습니다.

1. 모든 사용자에게 직접 쓰기 액세스 권한을 부여하여, 저장소 파일 시스템을 실수로 삭제하거나 손상시킬 수 있습니다.
2. 모든 네트워크 파일 공유 프로토콜이 Subversion에 필요한 잠금을 지원하지는 않습니다. 어느 날 저장소가 미묘하게 손상된 것을 발견할 수 있습니다.
3. 액세스 권한을 정확하게 설정해야 합니다. SAMBA는 이 점에서 특히 어렵습니다.
4. 어떤 사람이 저장소 형식을 업그레이드하는 최신 버전의 클라이언트를 설치하면, 다른 모든 사람들도 새 클라이언트 버전으로 업그레이드하기 전까지는 저장소에 액세스할 수 없게 됩니다.

가장 좋은 방법은 실제 서버 프로세스(예: Apache 또는 svnserve)를 설정하고, 서버가 액세스할 수 있는 로컬 파일 시스템에 저장소를 저장한 다음, 네트워크를 통해 저장소 서버를 사용할 수 있도록 하는 것입니다. 생각보다 쉽습니다. Subversion Book의 6장, 서버 구성에서 이 프로세스를 자세히 다룹니다.

네트워크 공유에 작업 사본을 저장할 수 있나요?

이는 네트워크 공유에 따라 다릅니다. 하지만 저희는 정말로, 정말로 이것을 하지 말라고 촉구합니다! Windows 서버를 사용하고 해당 네트워크 공유를 사용하더라도 fcntl() 파일 잠금은 완전히 신뢰할 수 없습니다. Samba 기반 공유에서는 모든 것이 불확실합니다. 이는 손상된 작업 사본을 얻게 될 것이고 데이터를 잃게 될 것이라는 의미입니다! 오늘이 아닐 수도 있고, 내일이 아닐 수도 있지만, 언젠가는 그렇게 될 것입니다.

정말로 네트워크 공유에 작업 사본을 저장해야 한다면, 해당 SQLite 프로젝트의 FAQ 항목을 자세히 살펴보십시오.

동일한 작업 사본에 다른 Subversion 클라이언트를 사용할 수 있나요?

예, 원할 때마다 한 클라이언트에서 다른 클라이언트로 변경할 수 있습니다. 클라이언트는 작업 사본과 작업 사본과 저장소 간의 상호 작용을 제어할 뿐입니다. 다른 클라이언트에서 사용되는 작업 사본 내부의 메타데이터는 동일합니다.

하지만 모든 클라이언트가 동일한 Subversion 라이브러리 버전을 사용하는 경우에만 다른 클라이언트를 사용할 수 있습니다. TortoiseSVN이 사용하는 Subversion 라이브러리 버전은 설치 프로그램 파일 이름에 표시되어 있으며, 다른 클라이언트도 유사한 표시를 가지고 있습니다. 이들 버전의 처음 두 자리가 일치하는지 확인해야 합니다. 예를 들어, Subversion 1.6.x를 사용하는 모든 클라이언트는 함께 사용할 수 있습니다 ('x'는 이 숫자가 호환성에 중요하지 않음을 나타냅니다).

또한 모든 클라이언트가 동일한 OS용으로 빌드되었는지 확인해야 합니다. 클라이언트 호환성은 특정 OS 유형에 대해서만 보장되며 메타데이터 표현이 다를 수 있습니다. 동일한 작업 사본에 기본 Windows 클라이언트와 Cygwin 클라이언트를 함께 사용해서는 안 됩니다. 그리고 네트워크를 통해 작업 사본을 공유하는 경우 동일한 작업 사본에 Linux 클라이언트와 Windows 클라이언트를 함께 사용해서는 안 됩니다.

TortoiseSVN이 텍스트 파일의 줄 바꿈을 즉시 변환할 수 있나요?

Subversion 책에서 svn:eol-style 속성에 대해 여기를 확인하십시오. 이 속성을 예를 들어 'native'로 설정하면 파일은 Linux에서 LF 줄 끝을 가지지만, Windows에서는 CRLF 줄 끝을 가집니다. TortoiseSVN으로 이러한 속성을 설정하는 방법을 보려면 여기에서 저희 문서를 읽으십시오.

디렉터리 속성 목록에 충돌이 있을 때 어떻게 충돌을 알아내나요?

충돌하는 속성이 있는 폴더 안에 dir_conflicts.prej라는 파일이 있을 것입니다. 해당 파일을 텍스트 편집기에서 열면 충돌하는 속성을 볼 수 있습니다. 유지하려는 속성을 선택하고 해당 속성으로 충돌하는 속성을 덮어쓰십시오.

파일을 실수로 제거했습니다. 어떻게 되돌리나요?

아직 변경 사항을 커밋하지 않았다면, 파일 또는 디렉터리를 삭제한 상위 폴더에서 되돌리기를 수행할 수 있습니다.

삭제된 파일을 이미 커밋했다면, 저장소 브라우저를 사용하여 파일이 여전히 존재했던 리비전으로 변경한 다음, 컨텍스트 메뉴에서 복사... 명령을 사용하십시오. 작업 사본의 경로를 대상으로 입력하면 삭제된 파일이 저장소에서 작업 사본으로 복사됩니다.

이 기술을 사용하여 삭제된 디렉터리도 복원할 수 있습니다.

이 트릭을 사용하여 파일/폴더를 복원한 후 로그 대화 상자에 해당 파일의 히스토리가 표시되지 않아도 걱정하지 마십시오. 히스토리는 여전히 존재합니다. SVN에서 파일을 복사하면 그 히스토리도 복사됩니다. 그러나 TSVN의 '로그 표시' 기본 설정은 '복사에서 중지'입니다. 이는 히스토리를 볼 때 분기 지점까지만 거슬러 올라간다는 의미입니다. 프로젝트의 실제 분기를 볼 때 대부분 해당 분기의 히스토리만 보고 싶기 때문입니다. '로그 표시'에서 전체 히스토리를 보려면 '복사에서 중지' 확인란을 선택 취소하고 '모두 가져오기'를 클릭해야 합니다.

링크를 마우스 오른쪽 버튼으로 클릭하면 여러 TortoiseSVN 컨텍스트 메뉴 항목이 나타납니다!

이는 설계된 대로입니다. 하나의 항목은 링크 자체(.lnk 파일)용이고, 다른 하나는 링크가 가리키는 대상용입니다. 이런 식으로 링크는 버전 관리될 수 있고 동시에 대상에 대한 작업을 허용함으로써 링크로서 작동해야 합니다. 실제로는 파일 메뉴에 최대 세 개의 항목이 있을 수 있습니다 (컨텍스트 메뉴는 두 개만 표시합니다).

Visual Source Safe처럼 '공유 파일'을 사용할 수 있나요?

예, 하지만 몇 가지 제한이 있습니다. "파일 외부" 기능을 사용하여 작업 사본과 동일한 저장소의 다른 부분에서 단일 파일을 가져올 수 있지만, 외부 저장소에서는 안 됩니다. 폴더를 공유할 수도 있으며, 이들은 어떤 저장소에서든 가능합니다. Subversion Book의 외부 정의 장을 참조하십시오.

서버 없이 TortoiseSVN을 사용할 수 있나요?

예, 가능합니다. file:// 프로토콜을 사용하여 로컬에서 저장소에 액세스할 수 있습니다. 하지만 이는 테스트 목적으로만 사용할 것을 강력히 권장합니다. 더 자세한 설명은 이 FAQ 항목을 참조하십시오.

TortoiseProc을 사용할 때 사용자 이름 & 비밀번호를 전송하는 방법이 있나요?

TortoiseSVN은 GUI 클라이언트이므로 필요할 경우 사용자 이름과 비밀번호를 요청합니다. 사용자 상호 작용 없이 (즉, 필요할 때 사용자 이름과 비밀번호를 입력할 필요 없이) 저장소에 대한 액세스를 자동화하려면 명령줄 클라이언트를 사용하십시오.

리비전 그래프는 어떻게 작동하나요?

리비전 그래프는 TortoiseSVN의 다른 기능들과는 조금 다릅니다. 파일이나 폴더가 복사, 이동, 분기 또는 태그된 모든 리비전과 함께 히스토리를 통해 해당 파일이나 폴더의 그래프를 보여줍니다.

저장소 루트에 대한 로그를 가져와야 하는 이유 또는 HEAD 리비전부터 첫 번째 리비전까지 전체 로그를 가져와야 하는 이유에 대해 질문하는 사람들이 종종 있습니다.

분명히 말씀드리지만, 이는 저희가 게으른 프로그래머이기 때문이 아니라 정말로 필요합니다.

리비전 그래프는 선택된 항목이 복사된 모든 리비전을 찾아 선택된 파일 또는 폴더의 히스토리를 보여줍니다. 그리고 그래프는 사용 가능한 정보를 사용하여 이를 수행해야 합니다.

선택한 파일 또는 폴더의 로그 메시지를 보면, 로그 대화 상자의 하단 창에서 선택한 리비전의 모든 영향을 받은 경로를 볼 수 있습니다. 이 정보가 리비전 그래프에 사용됩니다. 예를 들어 /trunk에 대한 로그만 표시하면 태그나 브랜치에서 발생한 리비전에 대한 항목이 로그 대화 상자에 표시되지 않습니다. 심지어 해당 로그에서 /trunk 자체를 태그하거나 브랜치한 항목도 볼 수 없습니다. --> 이것이 저장소 루트에 대한 로그를 가져와야 하는 이유입니다. 저장소 루트의 로그만이 경로가 언제 어디로 복사/분기/태그/이동되었는지 등 필요한 모든 정보를 제공합니다.

특정 범위에 대한 로그만 가져오고 모든 리비전을 가져오지 않는다면 (위의 /trunk 예시를 계속 사용하면) 트렁크가 분기되거나 태그된 리비전을 놓칠 수 있습니다. 그리고 해당 브랜치와 태그에 변경 사항이 있거나 리비전 범위 내에 여전히 존재하더라도, 그래프는 해당 브랜치/태그가 /trunk에서 생성된 것이 아니라 다른 경로에서 생성된 것임을 알 수 없습니다. 즉, 그래프는 불완전할 뿐만 아니라 잘못된 정보가 될 것입니다.

그리고 아니요: 저희는 그것을 절대 변경하지 않을 것입니다. 왜냐하면 가끔만 정확한 그래프보다 더 나쁜 것은 없기 때문입니다. 언제 그리고 그것이 정확한지 결코 알 수 없을 것이고, 이는 쓸모없는 것보다 더 나쁠 것입니다.

svn+ssh를 통해 변경 사항을 커밋할 때 로그에 '작성자'가 표시되지 않는 이유는 무엇인가요?

SSH가 인증 프로세스를 완전히 처리하므로 Subversion은 커밋하는 작성자를 인식하지 못합니다. 따라서 Subversion에 작성자를 알려주려면 URL 자체에 작성자를 지정해야 합니다. 예를 들어, svn+ssh://[email protected]와 같이 말이죠. 작업 사본을 체크아웃할 때 그렇게 해야 합니다.

TortoiseSVN이 파일이 수정되었음을 인식하지 못하는 이유는 무엇인가요?

파일을 수정했지만 TortoiseSVN이 파일이 수정되었음을 인식하지 못하는 경우, 먼저 해당 파일이 작업 사본의 내용과 실제로 다른지 확인하십시오.

파일에 수정 사항이 있다는 것을 확실히 알고 있고 커밋 대화 상자에 여전히 수정됨으로 표시되지 않는다면, 다음 사항을 확인하십시오.

• 파일 '최종 수정' 날짜가 변경되었는지 (헥스 편집기 같은 일부 도구는 이 시간을 재설정하는 경향이 있습니다)
• svn:eol-style 속성이 설정되어 있고 변경 사항이 줄 바꿈에만 있다면, Subversion 입장에서는 변경되지 않았으므로 파일이 수정됨으로 표시되지 않을 것입니다.

Subversion은 다음 접근 방식을 사용하여 파일이 변경되었는지 여부를 결정합니다.

1. '최종 수정' 날짜 및/또는 파일 크기가 변경되었습니까?
2. 그렇지 않다면: 파일은 수정되지 않았습니다.
3. 그렇다면: 파일 내용을 BASE 파일과 비교합니다.
4. 다른 첫 번째 바이트에서 중지하고, 파일을 수정됨으로 표시합니다.
5. BASE에 대해 다른 바이트가 없다면, 파일을 수정되지 않음으로 표시합니다.

파일을 제거하면 사라지는데, 어떻게 커밋하나요?

쉽습니다. 전체 디렉터리를 커밋하면 됩니다! 파일 옆의 탐색기 창에서 마우스 오른쪽 버튼을 클릭하고 커밋을 선택하십시오. 커밋 대화 상자는 추가되거나 삭제된 파일뿐만 아니라 모든 수정 사항을 표시할 것입니다.

SAMBA 공유의 작업 사본에 대한 권한 문제.

TortoiseSVN 1.5.x 이상으로 업그레이드한 후, 작업 사본이 SAMBA 공유에 저장되어 있다면 대부분의 Subversion 명령에서 "액세스 거부" 오류가 많이 발생합니다.

일부 사용자들은 SAMBA를 최신 버전으로 업그레이드한 후 문제가 해결되었다고 보고했습니다. 도움이 되지 않거나 업그레이드할 수 없다면, SAMBA 구성 파일에서 읽기 전용 파일을 삭제하도록 허용하십시오.

[global]
delete readonly = yes

[global]
create mask = 0644
force create mode = 0600
security mask = 0555
force security mode = 0600

저희가 받은 정보에 따르면 주요 문제는 SAMBA 3.2.3에서 수정되었습니다. svn:needs-lock 속성을 가진 파일을 읽기 전용으로 만드는 추가적인 문제가 있습니다. 이 문제는 SAMBA 3.2.6 또는 3.3.0에서 수정된 것으로 보고되었습니다.

탐색기와 파일/열기 대화 상자에서 탐색이 매우 느립니다.

액세스할 수 없거나 로그인하지 않아 해결되지 않은 네트워크 드라이브를 매핑한 경우, Windows가 드라이브에 액세스하려다가 실패하는 동안 파일 탐색이 응답하지 않을 수 있습니다. 드라이브 매핑을 해제하거나 액세스할 수 있는지 확인하십시오.

bugtraq: 속성이 저장소 브라우저에서 시작된 대화 상자에 대해 작동하지 않습니다.

이는 설계된 대로입니다. 저장소 브라우저는 속성을 읽지 않는데, 이는 원격으로 수행할 경우 매우 느린 작업이기 때문입니다. 로컬 작업 사본에서 읽을 때만 충분히 빠릅니다.

만약 TortoiseSVN이 해당 속성들을 저장소에서 직접 읽는다면, 가져오는 데 몇 초(심지어 몇 분!)가 걸릴 수 있습니다.

로그를 표시하면 자주 충돌이 발생합니다.

로그 캐시는 모든 저장소가 다른 UUID를 갖는 것에 의존합니다. 이에 대한 이유와 해결책에 대한 자세한 설명은 다음에서 확인할 수 있습니다: https://tortoisesvn.gisul.kr/logcacheuuids.html.

많은 Subversion 호스팅 회사들이 고객을 위해 새 저장소를 생성하지 않고 템플릿 저장소를 단순히 복사하는 실수를 저질렀다는 것을 알고 있습니다. 그런 호스팅 업체를 사용하고 있다면, 그들에게 이 문제를 해결하도록 요청하십시오.

작업 사본을 업데이트할 때, 새 파일이 추가되지 않습니다!

TortoiseSVN 1.6.0과 1.6.1 사이에서 추가된 폴더는 "이 항목만" 깊이로 추가되었습니다. 이는 작업 사본의 해당 부분에 대한 소위 "스파스 체크아웃"으로 이어졌습니다.

향후 이러한 문제를 방지하려면 TortoiseSVN의 최신 버전으로 업데이트하십시오.

스파스 작업 사본을 수정하려면 "업데이트" 대신 TortoiseSVN 하위 메뉴(탐색기에서 마우스 오른쪽 버튼 클릭)에서 "리비전으로 업데이트..." 명령을 사용하고 "업데이트 깊이" 콤보박스를 "완전 재귀"로 변경하십시오.

이슈/버그 X가 rXXX에서 수정되었다고 들었지만, 최신 릴리스에는 여전히 이 기능이 구현/수정되지 않았습니다?

저희의 릴리스 정책은 안정적인 브랜치에 새로운 기능이나 리소스 변경 사항을 절대 도입하지 않는 것입니다. 저희는 트렁크에서 작업하며, 버그를 수정하고, 새로운 기능을 도입하거나 기능의 동작을 변경합니다. 중요한 버그 수정만 안정적인 브랜치로 다시 병합되며, 안정적인 브랜치에서 릴리스를 생성합니다.

저희는 안정적인 브랜치에 새로운 버그가 유입되는 것을 방지하기 위해 이러한 정책을 가지고 있습니다. 결국, 그것은 안정적인 브랜치라고 불립니다.

요청하신 기능/보고된 버그는 트렁크에서 수정/구현되었지만, 이 정책으로 인해 안정적인 브랜치로 다시 병합되지 않았습니다. 따라서 최신 릴리스에서 변경 사항을 볼 수 없는 것입니다.

하지만 모험을 즐기신다면 나이틀리 빌드를 사용할 수 있습니다: https://nightlybuilds.tortoisesvn.net/latest/

TortoiseSVN은 Eclipse와 잘 작동하지 않습니다

Eclipse는 일반적인 작업의 일부로 디렉터리를 복사하며, Subversion 작업 사본에서는 .svn 디렉터리도 복사합니다. 이로 인해 TortoiseSVN은 bin 디렉터리에 버전 관리되는 파일이 있다고 생각하게 됩니다.

TortoiseSVN을 계속 사용하면서 이러한 일이 발생하지 않도록 하려면, Eclipse의 소스 제외 목록에 '**/.svn/'을 추가해야 합니다.

하지만 Eclipse에는 자체 Subversion 플러그인인 Subclipse가 있으며, 이는 Eclipse를 SVN 인식 상태로 만들고 문제를 근원에서 해결합니다. https://github.com/subclipse/subclipse에서 찾을 수 있습니다. Subclipse를 설치한 후에는 새로 체크아웃해야 합니다. 설치 전에 수행된 체크아웃은 수정하지 않습니다.

Internet Explorer에서 파일 업로드 시 보안 경고

Internet Explorer에서 웹 양식을 사용하여 파일을 업로드할 때, 프로그램이 웹 콘텐츠를 열려고 시도하고 있으며, TortoiseSVN이 원인이라고 지목하는 보안 경고를 받을 수 있습니다.

당황하지 마십시오! 이것은 Internet Explorer 보안 모델의 (잘못된) 기능입니다. TortoiseSVN은 셸 확장 기능이므로 아이콘 오버레이와 컨텍스트 메뉴를 제공하기 위해 파일 열기 대화 상자가 생성될 때마다 자동으로 로드됩니다.
경고를 중지하는 두 가지 방법이 있습니다.

1. TortoiseSVN 설정에서 아이콘 오버레이 섹션으로 이동하여 탐색기에서만 오버레이 및 컨텍스트 메뉴 표시 확인란을 선택합니다.
2. 경고가 나타나면 이 응용 프로그램에 대해 다시 표시 안 함으로 표시된 확인란을 선택합니다.

스마트 카드 삽입을 반복적으로 요청하는 대화 상자

스마트 카드 소프트웨어를 사용하는 경우, TortoiseSVN이 저장소에 연결을 시도할 때마다 스마트 카드를 삽입하라는 대화 상자가 나타날 수 있습니다.

안타깝게도 일부 스마트 카드 공급업체는 이를 버그가 아닌 기능으로 간주합니다. 비록 사용자들을 귀찮게 하는 것 외에는 아무런 목적도 없지만 말이죠.

저장소에서 인증서를 요청할 경우 TortoiseSVN이 Windows 인증서 저장소에 액세스하려고 시도하는 것을 방지하려면, 레지스트리 키 HKCU\Software\TortoiseSVN\OpenSSLCapi를 DWORD로 생성하고 값을 0으로 설정하십시오.

"작업 사본과 비교"가 구성된 Diff 뷰어를 사용하지 않습니다

로그 대화 상자에서 "작업 사본과 비교"를 실행하면, 다른 Diff 뷰어 도구를 사용하도록 구성했더라도 TortoiseMerge가 시작됩니다.

이것은 버그가 아닙니다. 이 명령은 두 파일을 비교하는 것처럼 보일 수 있지만 실제로는 그렇지 않습니다. 이 명령은 패치 파일을 생성한 다음 TortoiseMerge를 시작하여 해당 패치 파일을 작업 사본에 적용했을 때 어떤 모습일지 보여줍니다. 그리고 패치 파일을 적용할 수 있는 다른 UI 도구를 알지 못하므로 TortoiseMerge가 시작됩니다. 구성된 Diff 뷰어는 이 작업을 수행할 수 없습니다.

디버그 심볼은 어디에 있나요?

공식 릴리스와 나이틀리 빌드의 모든 디버그 심볼은 DrDump.com에 호스팅되어 있습니다.

디버그 심볼에 액세스하려면 디버거를 https://www.crash-server.com:8080/public/tsvn/71040F62-F78A-4953-B5B3-5C148349FED7/symsrv의 심볼 서버를 사용하도록 구성하십시오.

디버그 심볼 서버를 사용하는 방법을 알아보려면 이 문서를 참조하십시오.

... 작성자, 리비전, 날짜 및 커밋 시간과 같은 키워드 정보를 파일에 추가하나요?

Subversion 책에서 Subversion 속성 svn:keywords에 대해 읽어보십시오.

TortoiseSVN에서는 여기에 설명된 대로 속성을 설정하십시오.

... 파일명의 대소문자를 변경하나요?

Subversion은 Linux에서 사용되는 것과 같은 대소문자 구분 파일 시스템에서 작동하도록 설계되었습니다. Windows의 대소문자 비구분 파일 시스템에서는 예상대로 작동하지 않는 경우가 있습니다. 예를 들어, Makefile을 MAKEFILE로 이름을 변경하는 경우와 같이 대소문자만 변경되는 파일의 이름 변경이 그 예입니다. Subversion 1.7 이전에는 Subversion이 두 이름을 동시에 잠시 동안 존재하도록 요구했고 Windows는 이를 지원할 수 없었기 때문에 작업 사본 내에서 이를 쉽게 수행할 수 없었습니다.

가장 쉬운 방법은 저장소 브라우저를 사용하여 직접 이름을 변경하는 것입니다.

1. 작업 사본의 변경 사항을 커밋합니다.
2. 저장소 브라우저를 사용하여 저장소에서 파일을 직접 UPPERcase에서 upperCASE로 이름을 변경합니다.
3. 작업 사본을 업데이트합니다.

Subversion 1.7부터는 전체 작업 사본 구조가 변경되었으므로 더 이상 문제가 되지 않으며, 일반적인 TSVN->이름 바꾸기 명령을 사용하여 파일을 간단히 이름을 변경할 수 있습니다.

... 커밋 후 로그 메시지 또는 작성자를 변경하나요?

로그 대화 상자를 열고 편집하려는 리비전에서 마우스 오른쪽 버튼을 클릭합니다. 그런 다음 컨텍스트 메뉴에서 "작성자 변경" 또는 "로그 메시지 변경"을 선택합니다. 서버가 이러한 변경 사항을 허용하도록 하려면 작성자 또는 메시지 변경을 허용하는 pre-revprop-change 훅이 저장소에 설치되어야 합니다. 기본 설치는 작성자 및 로그 메시지 변경을 거부합니다.

... TortoiseSVN의 드롭다운 목록을 지우나요?

TortoiseSVN의 설정 대화 상자에서 저장된 모든 데이터를 지울 수 있습니다. 해당 버튼을 클릭하기만 하면 됩니다.

드롭다운 목록에서 단일 항목은 Shift-Delete를 눌러 영구적으로 제거할 수 있습니다.

... 컴퓨터에서 저장소를 완전히 제거하나요?

흠: 폴더를 선택하고 Delete 키를 누르십시오 (키보드의 키는 Del로만 표시될 수 있습니다).

진지하게 말해서, 숨겨진 파일이나 설정은 없습니다. 저장소는 하나의 폴더 트리에 완전히 포함되어 있습니다.

작업 사본도 마찬가지입니다. 작업 사본을 휴지통으로 보내면 작은 파일 수가 많아서 향후 삭제 작업이 심각하게 느려질 수 있습니다. 휴지통을 곧 비우는 것이 좋습니다.

... 로그를 텍스트 파일로 내보내나요?

로그 대화 상자를 사용하십시오. 원하는 모든 항목을 선택하고 Ctrl+C를 누르십시오. 그런 다음 즐겨 사용하는 텍스트 편집기에서 Ctrl+V (또는 붙여넣기)를 사용하십시오.

로그 메시지를 자동으로 처리하거나 XML 형식으로 필요한 경우 명령줄 클라이언트를 사용할 수 있습니다.

... 프로젝트 리비전 번호를 내 프로젝트에 가져오나요?

프로그램 버전 번호에 리비전 번호를 포함시키려면 추가 도구가 필요합니다. SubWCRev.exe 도구는 저희 웹사이트의 다운로드 페이지 또는 TortoiseSVN 폴더의 bin 아래에서 찾을 수 있습니다.

이 도구는 작업 사본 전체를 탐색하여 가장 최근 리비전을 찾습니다. 해당 리비전이 발견되면 다음 문자열의 모든 발생을 대체합니다.

$WCREV$

이 문자열은 작업 사본의 리비전 번호로 대체됩니다.

WCMODS?수정됨:수정되지 않음$

로컬 수정 사항이 있는 경우, 물음표와 콜론 사이의 문자열이 삽입됩니다. 로컬 수정 사항이 없는 경우, 콜론과 달러 기호 사이의 문자열이 삽입됩니다. 위 예시에서는 수정됨 또는 수정되지 않음입니다.

$WCDATE$

작업 사본의 가장 높은 리비전 날짜로 대체됩니다.

예를 들어, TortoiseSVN 소스 트리의 version.in 파일을 살펴보십시오. 이 파일은 TortoiseSVN 및 해당 리소스 파일에서 사용됩니다. SubWCRev.exe 도구는 빌드 스크립트에서 다음과 같이 호출됩니다: SubWCRev.exe path\\to\\working\\copy version.in version.h 이렇게 하면 위 모든 문자열이 작업 사본의 값으로 대체된 새 파일 version.h가 생성됩니다. version.h 파일은 프로젝트 자체에서 사용되며 버전 정보에 대한 리소스 파일에 포함됩니다.

... Subversion이 자동 병합을 수행하지 못하게 하나요?

일부 사람들은 Subversion이 업데이트 시 다른 사람의 변경 사항을 자신의 로컬 작업 사본 변경 사항과 자동으로 병합하는 것을 좋아하지 않습니다. 다음은 해당 파일들을 충돌 상태로 강제하여 원하는 대로 수동으로 병합할 수 있는 방법입니다.

1. TortoiseSVN->설정->Subversion 구성 파일에서 편집 버튼을 클릭합니다.
2. [helpers] 섹션에 다음 두 줄을 추가하여 변경합니다.

   diff-cmd = "C:\\false.bat"
   diff3-cmd = "C:\\false.bat"

   (이중 역슬래시에 유의하십시오)
3. 두 줄로 구성된 C:\false.bat 파일을 생성합니다.

   @type %9
   @exit 1

이것은 자동 병합이 매번 실패하게 만들어 파일을 충돌 상태로 강제합니다.

궁금한 'type %9' 줄의 이유는 diff3-cmd가 병합된 출력을 표준 출력으로 보내기 때문입니다. Subversion은 이를 가져와 로컬 파일을 병합 결과로 덮어씁니다. 이 줄을 추가하면 빈 로컬 파일을 얻는 것을 방지합니다.

... 현재 샌드박스/저장소가 무엇인지 확인하나요?

작업 사본의 폴더를 마우스 오른쪽 버튼으로 클릭하고 탐색기 컨텍스트 메뉴에서 "속성"을 선택합니다. 그런 다음 속성 대화 상자에서 "Subversion" 탭으로 전환합니다. 거기에서 선택한 폴더에 대한 모든 종류의 정보를 볼 수 있으며, 어떤 URL을 가리키는지도 포함됩니다.

이 정보를 보는 또 다른 빠른 방법은 컨텍스트 메뉴에서 "재배치"를 선택하고 첫 번째 URL을 확인하는 것입니다. WC를 재배치하고 싶지 않으므로 이 대화 상자를 취소하십시오.

... TortoiseSVN을 자동/무인으로 설치하나요?

다음과 같이 MSI 설치 프로그램을 시작하십시오.

'XXX.svn-base'를 'XXX.tmp'로 복사/이동할 수 없습니다: 지정된 파일을 찾을 수 없습니다.

이 오류 메시지는 일반적으로 작업 사본을 업데이트하려고 할 때 발생합니다. 이 오류의 원인은 다음 중 하나입니다.

• 실제로 저장소에 이름의 대소문자만 다른 두 개의 파일이 있습니다. Windows 파일 시스템은 대소문자를 구분하지 않으므로 Windows 체크아웃에서는 이 방법이 작동할 수 없습니다. 파일 중 하나가 실수로 추가되었을 가능성이 높으므로, 어떤 파일인지 알아내고, 잘못된 파일에 변경 사항이 커밋되지 않았는지 확인한 다음 삭제해야 합니다.
• 유효하지 않은 (Windows에서 유효하지 않은) 파일 이름을 가진 파일이 있습니다. 예를 들어 "con", "lpr", "com" 등과 같은 이름은 장치 이름이므로 Windows에서 유효하지 않습니다. 물론 "/\*?:|" 및 기타 특수 문자가 포함된 이름도 Windows (NTFS 및 FAT)에서는 불가능합니다.

예, 이 경우 오류 메시지가 실제로 도움이 되지 않는다는 것을 알고 있습니다. 하지만 이 오류 메시지는 저희가 자체적으로 변경할 수 없는 Subversion 라이브러리에서 비롯됩니다.

이 문제를 해결하고 다시 발생하지 않도록 하는 몇 가지 방법이 있습니다. 이 지침을 살펴보십시오.

'.svn/tmp/entries'를 '.svn/entries'로 이동할 수 없습니다: 파일 또는 디렉터리가 손상되었거나 읽을 수 없습니다.

이 오류 메시지는 일반적으로 작업 사본을 업데이트하거나 커밋하려고 할 때 발생하며, Windows 7 시스템에서 흔히 나타나는 것으로 보입니다. 이는 Subversion이 이동하거나 수정해야 하는 파일에 대해 다른 프로세스가 핸들을 보유하고 있기 때문입니다. 이는 바이러스 스캐너일 수 있습니다. 바이러스 스캐너를 구성하여 작업 사본과 저장소가 스캔에서 제외되도록 하십시오.

참고: Windows 7에는 이 오류 메시지가 필요 이상으로 많이 나타나게 하는 버그가 있습니다. 이 버그는 서비스 팩 1에서 수정되었습니다. 자세한 내용은 이 게시물을 참조하십시오.

파일 'XXX\nnn-n.txn\changes'를 열 수 없습니다: 다른 프로세스에서 사용 중이므로 프로세스가 파일에 액세스할 수 없습니다

이 오류를 보고하는 사람들은 종종 무작위로 발생하며, 대규모 커밋 도중에 발생하는 경우가 많다고 말합니다. 커밋을 다시 시도하면 성공할 수도 있고 다른 지점에서 실패할 수도 있습니다.

가장 가능성이 높은 원인은 바이러스 스캐너가 불필요하게 파일 핸들을 열고 있는 것입니다. 스캐너를 비활성화하거나 저장소를 무시하도록 설정해 보십시오.

유사한 오류가 작업 사본에서도 발생할 수 있습니다. 거기서 .svn 폴더를 무시해 보십시오.

'XXX'를 추가하지 못했습니다: 동일한 이름의 개체가 이미 존재합니다

이 오류 메시지는 일반적으로 작업 사본을 업데이트하려고 할 때 발생합니다. Subversion은 기존 로컬 데이터를 삭제하거나 덮어쓰지 않기 때문에 발생합니다. 이 오류가 발생하는 세 가지 이유가 있을 수 있습니다.

1. 최근에 다른 사람이 추가한 파일과 이름이 같은 로컬 비버전 관리 파일이 있습니다. 이 경우 해결책은 로컬 파일을 다른 곳으로 이동(또는 이름 변경)한 다음 업데이트하는 것입니다. 그 후에 두 파일을 어떤 식으로든 결합해야 할지, 아니면 이름 선택이 순전히 우연의 일치인 경우 파일에 다른 이름을 지정할지 결정할 수 있습니다.
2. 저장소에서 파일 이름이 변경되었지만, Install.txt가 install.txt로 변경된 것처럼 대소문자만 다르고 로컬 변경 사항이 있는 경우입니다. 업데이트할 때, 수정된 로컬 파일이 버전 관리되지 않은 파일로 나타나는 상황(1)에 처하게 됩니다. 파일을 다른 곳으로 이동하고 업데이트한 다음, 문제를 해결하십시오.
3. 실제로 저장소에 이름의 대소문자만 다른 두 개의 파일이 있습니다. Windows 파일 시스템은 대소문자를 구분하지 않으므로 Windows 체크아웃에서는 이 방법이 작동할 수 없습니다. 파일 중 하나가 실수로 추가되었을 가능성이 높으므로, 어떤 파일인지 알아내고, 잘못된 파일에 변경 사항이 커밋되지 않았는지 확인한 다음 삭제해야 합니다.

'<경로>'의 OPTIONS: 401 인증 필요 <URL>

버전 1.4.x로 업그레이드할 때 갑자기 저장소에 더 이상 액세스할 수 없게 됩니다. 모든 시도는 '경로'의 OPTIONS: 401 인증 필요 'url' 오류 메시지와 함께 거부됩니다.

이 문제는 버전 1.4.x에서 활성화된 SSPI를 통한 자동 인증 때문입니다. 즉, TortoiseSVN은 이제 Windows 도메인 컨트롤러에 로그온된 사용자의 자격 증명으로 자동으로 인증을 시도합니다.

도메인 컨트롤러에 SSPI를 통해 인증하도록 서버를 설정했고, 도메인 컨트롤러에 GUEST 사용자 계정이 활성화되어 있지 않다면 문제가 없을 것입니다. 하지만 GUEST 사용자 계정이 활성화되어 있다면, 모든 인증은 해당 사용자로 성공하게 되는데, 일반적으로 GUEST 사용자에게 저장소 액세스 권한을 부여하지 않습니다. 이것이 인증은 성공하지만 권한 부여는 실패하는 이유입니다.

실패할 수 있는 또 다른 이유는 워크스테이션에 로그인하는 데 사용하는 계정과 다른 계정으로 저장소 액세스를 설정한 경우입니다 (하지만 이 경우 애초에 왜 SSPI 인증을 사용하고 있는지 궁금합니다).

이 문제를 해결하려면 다음과 같은 옵션이 있습니다.

• 도메인 컨트롤러에서 GUEST 계정을 비활성화합니다.
• 워크스테이션과 저장소 액세스에 동일한 계정을 사용합니다.
• 저장소에 대한 SSPI 인증을 비활성화합니다.
• 사용자 이름의 대소문자를 확인하십시오. 액세스 파일의 사용자 이름을 소문자로 변경하는 것도 이 문제를 해결할 수 있습니다.

이 클라이언트는 작업 사본 'XXX'와 함께 사용하기에는 너무 오래되었습니다

전체 오류 메시지는 다음과 같습니다: '.' 작업 사본과 함께 사용하기에는 이 클라이언트가 너무 오래되었습니다. 최신 Subversion 클라이언트를 다운로드하십시오.

이 오류 메시지는 더 높은 Subversion 버전과 연결된 Subversion 클라이언트를 사용한 다음, 더 낮은 버전과 연결된 Subversion 클라이언트로 명령을 실행하려고 할 때 발생합니다. 예를 들어, 작업 사본에 1.4.x 클라이언트를 사용했고, 이제 동일한 작업 사본에 svn 1.3.x 클라이언트를 사용하려고 할 때 발생합니다.

이유는 Subversion 1.4 이상 버전은 모든 명령에서 작업 사본을 투명하게 업그레이드하기 때문입니다. 하지만 작업 사본 형식이 업그레이드되면, 이전 클라이언트는 새 형식을 모르기 때문에 더 이상 작업 사본에 액세스할 수 없습니다.

이 문제를 '해결'하는 유일한 방법은 이 오류 메시지를 발생시킨 클라이언트를 업그레이드하는 것입니다. 또는 이전 클라이언트로 새로 체크아웃하는 것입니다.

작업 사본이 오래되었습니다

이 오류 메시지는 작업 사본에 변경한 내용을 커밋하려고 할 때 발생합니다. 일반적으로 이 문제는 다른 사람이 저장소에서 당신이 변경한 파일과 동일한 파일(들)을 변경했기 때문에 발생합니다.

이는 업데이트 명령을 사용하여 작업 사본을 저장소와 동일한 수준으로 업데이트해야 함을 의미합니다.

특히 저장소가 변경되지 않았음을 알고 있는 경우, 왜 이렇게 해야 하는지 명확하지 않을 수 있습니다. 답은 간단합니다. 작업 사본은 커밋에 의해 완전히 업데이트되지 않습니다. 변경된 파일과 폴더만 자동으로 업데이트됩니다. 새로 생성된 저장소에서 다음 예를 고려해 보십시오.

Add Folder in revision 1
Add File1 and File2 in revision 2
Modify File1 and commit in revision 3

이제 저장소는 리비전 3에 있지만, 작업 사본의 리비전은 다음과 같습니다.

Folder       : revision 1
Folder/File1 : revision 3
Folder/File2 : revision 2

이제 File2를 수정하고 커밋하려고 하면 실패합니다. 클라이언트는 저장소에 File2가 로컬 수정 사항과 함께 리비전 2에 있다고 알리지만, 저장소는 이미 리비전 3에 있습니다. 그런 다음 업데이트를 수행하면 File2도 리비전 3에 있게 됩니다 (물론 로컬 변경 사항은 그대로 유지됩니다).

브랜치나 태그를 생성하려고 할 때도 같은 일이 발생할 수 있습니다. 답은 항상 동일합니다. 작업 사본이 오래되었다면 업데이트하십시오!

표준 출력에 쓸 수 없습니다

TortoisePlink는 표준 plink 코드를 사용하지만, 윈도우리스 앱으로 컴파일되어 오류 메시지를 보낼 곳이 없습니다. TSVN 설정->네트워크에서 SSH 클라이언트 상자를 표준 plink를 사용하도록 설정하면 명령 상자에 오류 메시지가 표시됩니다. 일단 작동하면 동일한 매개변수로 TortoisePlink를 사용하십시오.

"표준 출력에 쓸 수 없음"은 Plink가 오류를 발생시키려 했지만, TortoisePlink가 DOS 상자를 제공하지 않으므로 오류 메시지를 쓸 표준 출력이 없다는 것을 의미합니다.

따라서 설정에 문제가 있습니다. 일반 plink 프로그램으로 시도하여 어떤 오류 메시지가 실제로 발생하는지 확인한 다음 설정을 수정하십시오.

일반 plink가 단순히 멈춘다면, 잘못된 매개변수가 전달된 것입니다 (설정 대화 상자, 네트워크 탭).

또 다른 가능성은 SSH 데몬이 svnserve 바이너리를 찾지 못할 가능성이 높다는 것입니다. 대상 사용자(여기서는 myuser)로 서버에 로그인하여 "which svnserve"를 입력하십시오. 바이너리 경로가 보이지 않는다면, 이 파일(및 다른 Subversion 바이너리도)을 이 사용자에게 전역적으로 액세스 가능하도록 만드십시오.

400 잘못된 요청

'...'에서 REPORT 요청 실패 '...'의 REPORT: 400 잘못된 요청 (http://...)

DAV 요청을 차단하는 방화벽 뒤에 있습니다. 대부분의 방화벽이 그렇습니다. 관리자에게 방화벽 변경을 요청하거나, http:// 대신 https://로 저장소에 액세스하십시오. 그렇게 하면 SSL 암호화를 사용하여 저장소에 연결하므로 방화벽이 간섭할 수 없습니다 (SSL 포트를 완전히 차단하지 않는 한).

또한 일부 바이러스 스캐너(예: Kaspersky)는 이 오류를 유발하는 것으로 알려져 있습니다.

403 금지됨

PROPFIND 요청 실패: 403 금지됨

실제 저장소 경로 대신 저장소의 상위 경로를 입력했기 때문일 것입니다. 액세스하려는 저장소 이름을 URL에 추가해 보십시오. 또한 저장소 이름 뒤에 후행 '/' 슬래시를 URL에 추가해야 합니다.

실제 오류에 대한 자세한 내용은 Apache 오류 로그를 찾아보십시오.

405 HTTP 메서드 허용되지 않음

PROPFIND 요청 실패 - 오류 405 HTTP 메서드 허용되지 않음

이 메시지는 여러 가지 형태로 나타납니다. 다음 경우에 이 오류를 볼 수 있습니다.

• PROPFIND 요청 실패 오래된 버전의 TortoiseSVN을 사용하여 저장소 자체 대신 저장소의 상위 경로를 탐색하려고 했습니다. 액세스하려는 저장소 이름을 추가하거나 TortoiseSVN을 1.2.3 이상으로 업그레이드하십시오.
• PROPFIND 요청 실패 입력한 URL 끝에 '/' 슬래시를 추가하는 것을 잊으셨습니다. 이전 버전의 TSVN은 저장소 이름 뒤에 '/'가 있어야 합니다. 이를 잊으면 TSVN이 URL에서 저장소 이름을 제거하고 상위 디렉터리에 액세스하려고 시도합니다.
• PROPFIND 요청 실패 DAV 요청을 허용하지 않는 프록시를 통해 저장소에 액세스하려고 합니다. 일반적으로 웹 브라우저로는 저장소를 잘 탐색할 수 있지만, SVN 클라이언트를 사용할 때만 이 오류가 발생합니다. 프록시/방화벽 서버를 구성하여 DAV 요청을 허용하도록 해야 합니다. 또는 http 대신 https를 사용해 보십시오. 대부분의 프록시는 암호화된 네트워크 패킷을 분석할 수 없으므로 더 이상 DAV 요청을 차단할 수 없습니다.
  이 오류의 또 다른 가능성은 컴퓨터에서 실행 중인 바이러스 스캐너/방화벽입니다. 많은 경우 사용자가 알아차리지 못하게 DAV 요청을 필터링합니다. 스캐너/방화벽을 비활성화해 보십시오.
• 잠금 요청 실패 저장소에 더 이상 존재하지 않는 작업 사본의 파일을 잠그려고 했습니다. 파일을 잠그기 전에 작업 사본을 업데이트하십시오.

실제 오류의 원인에 대한 자세한 내용은 Apache 오류 로그를 찾아보십시오.

SVN+SSH: 연결이 예기치 않게 종료되었습니다.

이전에는 작동했던 svn+ssh://[email protected] 형식의 svn+ssh 연결이 TortoiseSVN 1.5에서 작동하지 않는다는 보고가 있습니다. 이는 plink와 관련이 있으며, PuTTY에 기본 호스트 이름이 설정되어 있는 경우 발생합니다.

이 경우 regedit 또는 regedt32를 사용하여 HKEY_CURRENT_USER/Software/SimonTatham/Putty/Sessions/Default%20Settings/HostName을 지우면 해결할 수 있습니다.

• 계정에 ssh로 접속합니다.
• cd ~
• cp /etc/bashrc .bashrc
• nano .bashrc
• "mesg y" 줄 앞에 #을 붙여 주석 처리합니다.
• 종료하려면 Ctrl+X를 누르고, 저장할지 묻는 메시지가 나타나면 Y를 누르십시오.