1Chapter. 고급 주제

1.1.1. 설정 area의 레이아웃

svn커멘드 라인 클라이언트가 최초로 실행되면(자), 그것은 유저마다의 구성 area를 만듭니다. Unix풍의 시스템이라면, 이 area는 유저의 홈 디 렉토에,. subversion 라는 이름의 디렉토리로서 준비됩니다. Win32 시스템에서는, Subversion은 Subversion라는 이름의 폴더를 만듭니다. 보통으로는 유저 프로파일 디렉토리의Application Data area 의 내부가 됩니다. 그러나, 이 플랫폼에서는, 완전한 장소는 시스템 마다 차이가 나, 진짜 장소는 Windows 레지스트리로 설정되어 있습니다. 유저마다의 설정 area는, Unix 에서의 이름이다. subversion (을)를 사용해 참조하기로 하겠습니다.

유저마다의 설정 area에 가세해, Subversion은 시스템 전체의 설정 area도 이해할 수가 있습니다. 이것은 시스템 관리 책임자에 있는 머신상에서의 모든 유저에 대한 디폴트를 설정하는 힘을 줍니다. 시스템 전체 의 설정 area는 필수의 폴리시가 있는 것은 아닙니다유저 마다의 설정 area는, 시스템 전체의 area를 덧쓰기해,svn 프로그램에게 주는 커멘드 라인 인수는 행동을 결정하는 마지막 장소에 됩니다. Unix풍의 플랫폼에서는, 시스템 전체의 설정 area는 /etc/subversion 디렉토리에 있다고 기대되어 있습니다. 그것은 또, 공통 어플리케이션 area의 내부에 있다 Subversion디렉토리를 보러 갑니다. (그리고 또, 그것은 Windows 레지스트리에 의해 지정됩니다만) 유저마다의 경우 (와) 달리,svn 프로그램은 시스템 전체의 설정 area를 만들려고는 하지 않습니다.

. subversion 디렉토리는 현재로서는 세 개의 파일을 포함하고 있습니다두 개의 설정 파일 (config 와 servers입니다), 거기에 README.txt 파일로, 이것은 INI 형식을 설명하는 것입니다. 그러한 생성시에는, 파일은 Subversion 하지만 서포트하는 각각의 옵션의 디폴트값이 들어오고 있어 대부분이 comment out 되고 있어, 게다가 어떻게 키에 대한다 값이 Subversion의 행동에 영향을 줄까라고 하는 것에 대하여, 텍스트의 설명 돌출하고 그룹화 되고 있습니다. 무엇인가의 행동을 바꾸기 위해서(때문에)는 관련하는 설정 파일을 텍스트 문자 편집기로 열려, 필요한 옵션치로 수정하는 것만이 필요합니다. 만약 항상 설정 파일중에 디폴트의 설정 (을)를 하고 싶은 경우는, 단지 그 파일을 삭제해, 무엇인가 무해인svn개만, 예를 들어 svn --version의 같은 것을 실행하면(자), 없어진 파일은 디폴트 상태로 재생성됩니다.

유저마다의 설정 area는 인증 데이터의 캐쉬도 포함합니다. auth 디렉토리는 Subversion로 서포트되고 있는 다양한 인증 방법으로 이용된다 캐쉬 정보의 요소를 포함한 서브 디렉토리의 모임을 보관 유지합니다. 이 디렉토리는 유저 자신만이 그 내용을 읽을 수가 있는 것 같은 형태에 작성됩니다.

1.1.2. 설정과 Windows의 레지스트리

보통 INI 베이스의 설정 area에 가세해, Windows 플랫폼상에서 실행되어 있는 Subversion 클라이언트는 Windows의 레지스트리도 설정 데이터를 격납하는 장소 (으)로서 이용할 수가 있습니다. 옵션명과 그 값은 INI 파일중과 같다 입니다. "file/section" 의 계층 관계도 보존됩니다. 조금 다르다 방법에 따릅니다만이 방법에서는, 파일과 섹션은 단지 레지스트리 키의 트리의 계층 밖에 지나지 않습니다.

Subversion은 시스템 전체의 설정치를 HKEY_LOCAL_MACHINE\Software\Tigris.org\Subversion키 의 원으로 검색합니다. 예를 들어global-ignores 옵션, 이것은config 파일의miscellany 섹션에 있습니다만,HKEY_LOCAL_MACHINE\Software\Tigris.org\Subversion\Config\Miscellany\global-ignores에 찾아낼 수가 있습니다. 유저마다의 설정치는 HKEY_CURRENT_USER\Software\Tigris.org\Subversion. 의 아래에 격납될 것입니다.

레지스트리 베이스의 설정 옵션은, 파일 베이스의 나머지의 부분을 검색하기전에 검색됩니다. 그래서, 이러한 옵션은, 설정 파일중에서 발견된 값에 의해 덧쓰기 됩니다. 바꾸어 말하면(자), 설정의 우선권은 Windows 시스템의 경우, 이하의 순서가 되는 것이 프로텍션되고 있습니다:

1. 커멘드 라인 옵션

2. 유저마다의 INI 파일

3. 유저마다의 레지스트리치

4. 시스템 전체의 INI 파일

5. 시스템 전체의 레지스트리치

또, Windows 레지스트리는"comment out" (와)과 같은 개념을 서포트하고 있지 않습니다. 그러나, Subversion은, 키의 이름이 해시 캐릭터(#)로 시작되는 것 같은 모든 옵션을 무시합니다. 이것으로 실제로는 Subversion의 옵션 (을)를, 레지스트리로부터 완전하게 키를 지우지 않고 comment out 할 수가 있습니다. 분명하게, 그 옵션의 설정 작업은 간단하게 하고 있습니다.

svn 커멘드 라인 클라이언트는 Windows의 레지스트리에 기입하는 것은 결코 않고, 거기에 디폴트의 설정치를 만들려고도 하지 않습니다. 필요한 키는 REGEDIT프로그램으로 만들 수가 있습니다. 다른 방법 (으)로서는,. REG 파일을 만들어, 익스플로러 조가비로부터 그 파일을 더블 클릭 하면(자), 그 데이터가 레지스트리에 merge 됩니다.

REGEDIT4

[HKEY_LOCAL_MACHINE\Software\Tigris.org\Subversion\Servers\DEFAULT]
"#http-proxy-host"=""
"#http-proxy-port"=""
"#http-proxy-username"=""
"#http-proxy-password"=""
"#http-proxy-timeout"="0"
"#http-compression"="yes"

[HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\auth]
"#store-password"="no"

[HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\helpers]
"#editor-cmd"="notepad"

[HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\miscellany]
"#global-ignores"="*. o *. lo *. la #*# . *. rej *. rej . *~ *~ . #*"

이 예는,. REG 의 내용을 나타낸 예입니다만, 그 안에는, 자주(잘) 이용되는 설정 옵션의 대부분그 디폴트치가 있습니다. 시스템의 설정(예를 들어 네트워크 프록시에 관한 옵션) 라고 유저마다의 설정(이용하는 에디터, 패스워드, 등)의 양쪽 모두가 있는 것에 주의해 주세요. 한층 더 모든 옵션은, comment out 되고 있게도 주의해 주세요. 옵션명의 선두의 해시 캐릭터 (#)(을)를 없애는 것만으로, 바라고 있는 값으로 설정하는 것이 할 수 있습니다.

1.1.3. 설정 옵션

이 장에서는, 특정의 실행시 옵션에 대해 논의합니다. 현재 Subversion 하지만 서포트하고 있는 것에 임해서입니다.

[groups]
beanie-babies = *. red-bean.com
collabnet = svn.collab.net

[beanie-babies]


[collabnet]

1.2.1. 왜 속성은 물건이?

속성은 작업 카피에 매우 도움이 되는 정보를 추가할 수가 있습니다. 실제, Subversion 자신도 특수한 정보를 기록하는데 속성을 사용하고 있어, 그것은 어느 특정의 처리가 필요하게 되어 있는 것을 나타내는 것 같은 때에 사용하고 있습니다. 같이 유저는 자기 자신의 목적을 위해서(때문에)도 속성을 사용한다 일이 생깁니다. 물론 속성으로 완성되는 것은 모두, 버전화 한 파일에서도 할 수 있습니다만, 우선은 이하와 같은 Subversion 속성의 사용법의 예를 봐 주세요.

아선반은, 많은 디지털 사진을 보이기 위한 웹 사이트를 설계하고 있어, 타이틀과 일자를 붙여 표시하고 싶다고 합니다. 여기서, 사진의 내용은 항상 변화하므로, 이 사이트의 관리를 할 수 있는 한 자동화하고 싶다고 생각하고 있습니다. 각각의 사진은 매우 크기 때문에, 이러한 경우의 상투수단으로서 당신은 사이트를 온 사람에게 작은 엄지손가락의 화상을 준비하고 싶다고 합니다. 이것을 보통 파일로 할 수도 있습니다. 즉, 디렉토리에 image123.jpg 와 image123-thumbnail.jpg 의 양쪽 모두를 두면 좋습니다. 혹은 양쪽 모두의 파일명칭을 함께 해, 별디렉토리에 있어도 괜찮네요. thumbnails/image123.jpg와 같은 느낌입니다. 타이틀과 일자에 대해서도 같은 방법을 취할 수가 있어 이것도 또, 원래의 화상 파일과는 다른 물건이 됩니다. 곧, 파일의 트리는 뒤죽박죽 (이)가 되어, 새로운 사진이 사이트에 추가될 때마다, 사이트의 데이터 몇배에도 부풀어 오릅니다.

Subversion의 파일 속성을 사용한 같은 설정을 생각해 봅시다. 어느 화상 파일image123.jpg와 그 파일 의 속성으로서 설정하는caption, datestamp, 그리고 thumbnail가 있는 곳(중)을 상상해 주세요. 이렇게 스치고는, 작업 카피의 디렉토리는 좀 더 관리하기 쉽고 됩니다실제 이것으로 화상 파일 이외가 아무것도 없게 보입니다. 그러나, 당신의 자동 스크립트는 좀 더 많은 일을 알고 있습니다. 그것은svn (혹은 게다가 Subversion 언어 제휴를 사용할 수도 있는 > 참조)를 사용해 확장 정보를 추가합니다만, 그것은 당신의 사이트가, 인덱스 파일을 읽거나 복잡한 파일 패스 조작의 구조를 만지는 것 없이 , 표시할 필요가 있다 물건입니다.

Subversion의 속성을 어떻게 사용할까는 당신 하기 나름입니다. 벌써 지적했다 같게, Subversion은 자기 자신이 사용하는 속성을 가지고 있어, 이 장의 나중에 조금 설명합니다. 그러나, 우선은,svn 프로그램 (을)를 사용해, 어떻게 옵션을 조작할까를 생각합시다.

1.2.2. 속성의 조작

svn 커멘드에는 파일과 디렉토리의 속성 (을)를 추가하거나 수정하거나 하는 몇개의 방법이 있습니다. 짧은 가독인 속성을 신규에 추가하는 1번 간단한 방법은 속성의 이름과 값을propset 서브 커멘드로 지정하는 것입니다.

$ svn propset copyright '(c) 2003 Red-Bean Software' calc/button.c
property `copyright' set on 'calc/button.c'
$

그러나, 속성치에 대해서 Subversion가 가지는 유연성에 대해서는 벌써 실컷 말해 왔습니다. 만약, 복수행 텍스트, 또는 바이너리치를 속성치에 하고 싶다고 생각하고 있다면, 커멘드 라인으로부터 그 값을 입력하고 싶지는 않으면 생각합니다. 그래서propset 서브 커멘드는 --file(-F) 옵션을 사용해, 새로운 속성값이 들어왔다 파일의 이름을 지정할 수도 있습니다.

$ svn propset license -F /path/to/LICENSE calc/button.c
property `license' set on 'calc/button.c'
$

propset 커멘드 고기원네라고,svn 프로그램은propedit 커멘드도 준비해 있습니다. 이 커멘드는, 설정된 에디터를 사용해(>참조) 속성을 추가하거나 수정하거나 합니다. 이 커멘드를 실행하면(자)svn 는 현재의 속성치를 기입했다 일시파일을 만들어 에디터를 기동합니다. (새로운 속성을 추가하는 경우는 이것은 비웁니다). 그리고, 자신이 바라는 것 같은 값이 될 때까지 새로운 속성치 (을)를 에디터를 사용해 수정해, 일시파일을 보존하고 나서 에디터를 빠집니다. Subversion은 속성의 값이 변경된 것을 확인하면(자), 그것을 새로운 속성치 (으)로서 받아들입니다. 만약 에디터를 변경하는 일 없이 빠지면, 속성치의 변경은 일어나지 않습니다.

$ svn propedit copyright calc/button.c  ### exit the editor without changes
No changes to property `copyright' on `calc/button.c'
$

다른svn커멘드와 같게, 속성에 관한 이러한 커멘드도 복수 패스에 대해서 한 번에 실행할 수가 있습니다. 이것은 하나의 커멘드로 복수의 파일상의 속성을 수정하는 것을 가능하게 합니다. 예를 들어, 이하와 같은 일이 생깁니다:

$ svn propset copyright '(c) 2002 Red-Bean Software' calc/*
property `copyright' set on 'calc/Makefile'
property `copyright' set on 'calc/button.c'
property `copyright' set on 'calc/integer.c'

$

이러한 속성의 추가나 편집은, 보관되고 있는 속성치를 간단하게 취득 할 수 없으면, 별로 편리하지는 않습니다. 그래서 svn 프로그램은 파일이나 디렉토리에 보관되었다 속성의 이름과 값을 표시하기 위한 서브 커멘드를 둘준비해 있습니다. svn proplist는 패스상에 존재하는 속성의 이름의 일람을 표시합니다. 노드상의 속성명을 알 수 있어 버리면, 개별적으로 svn propget를 호출해 그 속성치를 요구하는 것이 할 수 있습니다. 이 커멘드는 주어진(하나 이상의) 패스와 프롭퍼티명 (으)로부터, 그 속성치를 표준 출력에 표시합니다.

$ svn proplist calc/button.c
Properties on 'calc/button.c':
  copyright
  license
$ svn propget copyright calc/button.c
(c) 2003 Red-Bean Software

proplist 커멘드의 변종으로서 모든 속성의 이름과 값의 양쪽 모두를 리스트 하는 것이 있습니다. 이것에는 단지, --verbose(-v) 옵션을 지정하면 OK입니다.

$ svn proplist --verbose calc/button.c
Properties on 'calc/button.c':
  copyright : (c) 2003 Red-Bean Software
  license : ================================================================
Copyright (c) 2003 Red-Bean Software.   All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions 
are met:

1.  Redistributions of source code must retain the above copyright
notice, this list of conditions, and the recipe for Fitz's famous
red-beans-and-rice.

마지막 프롭퍼티 관련 서브 커멘드는 propdel입니다. Subversion은 하늘의 값을 가지는 속성을 격납하는 것을 허락하므로,propedit 나 propset를 사용하는 것 만으로는, 속성을 삭제하는 것이 할 수 없습니다. 예를 들어 이 커멘드는 기대되는 결과로는되지 않습니다 :

$ svn propset license '' calc/button.c
property `license' set on 'calc/button.c'
$ svn proplist --verbose calc/button.c
Properties on 'calc/button.c':
  copyright : (c) 2003 Red-Bean Software
  license : 
$

속성의 삭제에는propdel 커멘드를 사용할 필요가 있습니다. 구문은 다른 속성 관련 커멘드와 잘 닮았습니다:

$ svn propdel license calc/button.c
property `license' deleted from ''.
$ svn proplist --verbose calc/button.c
Properties on 'calc/button.c':
  copyright : (c) 2003 Red-Bean Software
$

이것으로, 속성 관련의svn 서브 커멘드의 모두에게 대해 설명했으므로, 일상적인 Subversion 워크플로우에, 속성의 변경 하지만 어떠한 영향을 줄까를 봅시다. 전에 지적한 것처럼 파일과 디렉토리의 속성은, 보통 파일의 내용과 같이, 버전화 됩니다. 결과적으로, Subversion은 다른 사람이 한 수정점을 자기 자신 위에 merge 할 수가 있습니다. 물론 통상의 merge와 같이, 잘될지도 모르지않고, 충돌할지도 모릅니다.

$ svn propset svn:log '* button.c: Fix a compiler warning. ' -r11 --revprop
property `svn:log' set on repository revision '11'
$

그리고 파일의 내용의 경우와 같이, 속성의 변경은 로컬인 수정 밖에 지나지 않고,svn commit로 저장소(repository)에 커밋해 처음 수정이 확정합니다. 변경은 역시 간단하게 취소한다 일도 할 수 있는 svn revert 커멘드는 파일이나 디렉토리를 편집전 상태에 되돌려, 그 내용, 속성, 등 모두에 대해서도 그렇습니다. 게다가 svn status 나 svn diff 커멘드를 사용해, 파일이나 디렉토리 속성 상태에 대해 유용한 정보를 받을 수가 있습니다.

$ svn status calc/button.c
 M     calc/button.c
$ svn diff calc/button.c
Property changes on: calc/button.c
___________________________________________________________________
Name: copyright
   + (c) 2003 Red-Bean Software

$

status 서브 커멘드가M (을)를 최초의 칼럼이 아니고, 두번째의 칼럼에 표시하는데 주의입니다. 이것은,calc/button.c의 속성을 수정했지만, 파일의 내용은 변경하고 있지 않는 것을 나타내고 있습니다. 속성도 내용도 변경하면,M 는, 최초의 칼럼 에도 두번째의 칼럼에도 표시됩니다. (>참조).

% svn update calc
M  calc/Makefile.in
 C calc/button.c
Updated to revision 143.
$ 

$ svn status calc
 C     calc/button.c
?       calc/button.c.prej
$ cat calc/button.c.prej 
prop `linecount': user set to '1256', but update set to '1301'.
$

Subversion가 현재의 속성의 차이를 표시하는 표준적이 아닌 방법으로 눈치 채였을지도 모릅니다. svn diff 를 실행해, 출력을 패치 파일을 만들기 위해서(때문에) 리디렉트 할 수가 있습니다. patch 프로그램은 속성에 대한 패치를 무시합니다일반적으로 그것은 이해할 수 없는 쓰레기를 모두 무시합니다. 이것은 불행하게도 svn diff로 생성된 패치를 완전하게 적용하려면 , 속성의 수정에 대해서는 손으로 적용하지 않으면 안 된다고 하는 것을 의미합니다.

본 것처럼, 속성의 수정은 전형적인 Subversion의 워크플로우에는 별로 큰 영향을 주지 않습니다. 작업 카피를 갱신해, 파일과 디렉토리의 상태를 체크해, 자신이 한 변경점에 대해 보고해, 그러한 수정점을 저장소(repository)에 커밋한다고 하는 일반적인 패턴은 속성의 존재나 비존재 (와)과는 완전하게 무관계합니다. svn프로그램에는 몇개의 추가의 서브 커멘드가 있어, 실제로 속성 변경할 수가 있습니다. 그러나, 그것은, 속성 관련 커멘드의 눈에 보이는 유일한 비대상성입니다.

1.2.3. 특수한 속성

Subversion은 속성에 대해 특별한 폴리시를 갖고 있지 않습니다어떠한 목적으로도 사용할 수가 있습니다. Subversion은,svn:라고 한다 프레픽스가 붙은 속성명을 사용하는 것을 금지하고 있을 뿐입니다. 이것이, Subversion 자신이 사용하는 속성의 이름 공간입니다. 실제, Subversion은, 파일이나 디렉토리에 특수한 효과를 미 것 같은 어떤 종류의 속성을 정의하고 있습니다. 이 마디에서는 이 신비를 설명해, 어떻게 이것들 특수한 속성이, 당신의 Subversion 라이프를 조금 편하게 할까에 임해서 설명합니다.

$ svn propset svn:ignore -F . cvsignore .
property `svn:ignore' set on '. '
$

$ svn status calc
 M     calc/button.c
?       calc/calculator
?       calc/data.c
?       calc/debug_log
?       calc/debug_log. 1
?       calc/debug_log. 2. gz
?       calc/debug_log. 3. gz

calculator
debug_log*

$ svn status
 M     calc
 M     calc/button.c
?       calc/data.c

$ svn status --no-ignore
 M     calc/button.c
I      calc/calculator
?       calc/data.c
I      calc/debug_log
I      calc/debug_log. 1
I      calc/debug_log. 2. gz
I      calc/debug_log. 3. gz

Here is the latest report from the front lines.
$LastChangedDate$
$Rev$
Cumulus clouds are appearing more frequently as summer approaches.

$ svn propset svn:keywords "LastChangedDate Author" weather.txt
property `svn:keywords' set on 'weather.txt'
$

Here is the latest report from the front lines.
$LastChangedDate: 2002-07-22 21:42:37 -0700 (Mon, 22 Jul 2002) $
$Rev$
Cumulus clouds are appearing more frequently as summer approaches.

1.4.1. 일반적인, 벤더 브랜치(branch)를 관리하는 방법

벤더 브랜치(branch)의 관리는 일반적으로는 이런 식으로 합니다. 최상정도 디렉토리를 만들어(/vendor와 같은 것) 거기에 벤더의 브랜치(branch)를 둡니다. 그리고 최상정도 디렉토리의 사브디레트크리에 서드 파티의 코드를 임포트 합니다. 그리고 그 사브디레트크리를, 적당한 장소에 있는, 자신의 주계 개발의 브랜치(branch)에 카피합니다(예를 들어/trunk등) 로컬인 변경은 항상 주계 개발 브랜치(branch)에 대해서 행합니다. 뒤쫓고 있는 코드의 새로운 릴리스마다, 그것을 벤더 브랜치(branch)에 가지고 가, 변경점을/trunk에 merge 합니다. 그리고, 로컬의 변경과 벤더의 변경동안의 충돌을 해소합니다.

아마, 예를 들면(자), 이 스텝을 확실히 할 수가 있을지도 알려지지 않습니다. 당신의 개발 팀이 서드 파티의 복잡한 수치계산 프로그램 라이브러리를 사용한 계산 프로그램을 만들고 있다고 합니다. 우선, 벤더 브랜치(branch)의 초기 생성을 해, 그리고 최초의 벤더 드롭 (을)를 임포트 합니다.

$ svn import /path/to/libcomplex-1. 0 \
             http://svn.example.com/repos/calc/vendor/libcomplex/current \
             -m 'importing initial 1.0 vendor drop'

이것으로, libcomplex의 원시 코드를/vendor/libcomplex/current 에 가지고 올 수가 있었습니다. 이 버전에 태그 짓고 해, (>참조), 주계 개발 브랜치(branch)에 카피하면 거기에 독자적인 수정을 더할 수가 있게 됩니다.

$ svn copy http://svn.example.com/repos/calc/vendor/libcomplex/current  \
           http://svn.example.com/repos/calc/vendor/libcomplex/1. 0      \
           -m 'tagging libcomplex-1. 0'

$ svn copy http://svn.example.com/repos/vendor/libcomplex/1. 0  \
           http://svn.example.com/repos/calc/libcomplex        \
           -m 'bringing libcomplex-1. 0 into the main branch'

프로젝트의 주계의 브랜치(branch)를 체크아웃 합니다. 이것은 최초의 벤더 드롭의 카피를 포함하고 있습니다그리고, libcomplex 코드의 수정에 들어갑니다. 이미 알고 있도록(듯이), 이것으로 수정된 libcomplex (은)는, 완전하게 계산 프로그램에 통합되고 있습니다. [8]

몇주간인가 끊어, libcomplex의 개발자는 프로그램 라이브러리의 새로운 버전을 릴리스 했던버전 1.1으로 합시다그것은 우리를 갖고 싶었다 몇개의 기능과 함수를 포함하고 있습니다. 그러나, 벌써 수중에 있는 버전에 대한 수정을 잃는 일 없이, 이 새롭다 버전에 업그레이드 하고 싶은 것입니다. 벌써 시사한 것처럼, 본질적으로 우리가 하지 않으면 안 되는 것은, libcomplex1. 1 의 카피 그리고 libcomplex1. 0 을 옮겨놓아 앞에 한 독자적인 수정을, 새로운 프로그램 라이브러리 의 버전에도 다시 적용하는 것입니다.

이 업그레이드를 하는데, 우리는 벤더 브랜치(branch)의 카피 (을)를 체크아웃 해,현재의버전을 새롭다 libcomplex1. 1 의 원시 코드로 옮겨놓습니다. 이 변경을 커밋했다 그리고, 우리의current 브랜치(branch)는 새롭다 벤더 드롭을 포함하고 있습니다. 이 버전을 태그않다 지워, 그리고 전에 태그 붙이고 한 버전과 새로운 현재의 버전의 사이의 차이 (을)를 주계 개발 브랜치(branch)에 merge 합니다.

$ cd working-copies/calc
$ svn merge http://svn.example.com/repos/vendor/libcomplex/1. 0      \
            http://svn.example.com/repos/vendor/libcomplex/current  \
            libcomplex
 # resolve all the conflicts between their changes and our changes
$ svn commit -m 'merging libcomplex-1. 1 into the main branch'

간단한 경우라면 이 새로운 버전의 서드 파티 툴은, 파일과 디렉토리의 관점으로부터 보면(자), 전의 버전과 같이 보입니다. 다른 말투를 하면(자), 어느 libcomplex 원시 파일도 삭제되거나 명칭 변경되거나 다른 장소로 이동하거나 하고 있지 않습니다 간단하게 말하면, 완전한 세계에서는, 우리의 수정은 새로운 프로그램 라이브러리의 버전에 예쁘게 적용되어 복잡한 일이나, 충돌은 일절 일어나지 않는다 그렇다고 하는 것입니다.

그러나, 모든 것이라는 것은 항상 단순하다라고는인가 선. 실제조사 있고, 원시 코드는 소프트웨어의 릴리스간에 여기저기 움직이는 것이 보통입니다. 이것은 우리의 수정이 새로운 버전의 코드 그렇지만 올바르다고 하는 것을 확인하는 작업을 복잡하게 하고, 새로운 버전 에서의 수정을 손으로 한번 더 할 필요가 있는 상황에, 간단하게 낙담해 버린다 일이 있습니다. Subversion가, 원시 파일의 히스토리에 대해 알아 있으면프로그램 라이브러리의 새로운 버전중의 merge의 스텝은 매우 단순하게 됩니다. 그러나, 우리는, Subversion에 원시 파일의 레이아웃이 벤더 드롭간에 어떤 바람으로 바뀌었는지를 가르쳐 줄 책임이 있습니다.

1.4.2. svn-load-dirs.pl

몇개의 파일의 삭제, 추가, 이동이 있던 벤더 드롭은 서드 파티 데이터의 업그레이드의 순서를 복잡하게 합니다. 그래서 Subversion은 이 수속을 지원하기 위해서 svn_load_dirs.pl스크립트를 준비해 있습니다. 이 스크립트는 일반적인 벤더 브랜치(branch)의 관리 수속으로 말한 것 같은 임포트의 스텝을 자동화해, 실수를 최소로 할 수가 있습니다. 서드 파티 데이터의 새로운 버전을 주계 개발 브랜치(branch)에 merge 한다 유익의 merge 커멘드를 사용할 책임은 아직 남아 있지만, svn_load_dirs.pl는 보다 빨리 간단하게 이 처리까지 도달하는 도움이 됩니다.

간단하게 말해,svn_load_dirs.pl 는 svn import 의 확장으로, 몇개의 중요한 특징을 가지고 있습니다:

• 언제라도, 이 프로그램을 실행해, 저장소(repository)에 있는 디렉토리를, 완전하게 거기에 일치한 외부 디렉토리에 가지고 가, 필요한 모든 추가, 삭제를 실행해, 한층 더 옵션으로 이동 처리도 실시합니다.

• 이 프로그램은, Subversion가 필요로 하는 중간적인 커밋간에 필요한 복잡한 일련의 처리를 주의 깊게 실행합니다예를 들어 파일이나 디렉토리의 명칭 변경을 2회하기 전 등.

• 그것은, 옵션으로 나등 있고 임포트 된 디렉토리를 태그 짓고 합니다.

• 그것은 옵션으로, 정규 표현에 성냥 하는 파일과 디렉토리 에 임의의 속성을 추가합니다.

svn_load_dirs.pl 는 세 개의 필수 파라미터를 취합니다. 처음은 작업 대상이 되는 베이스가 되는 Subversion 디렉토리의 URL 입니다. 이 인수의 후에는 URL가 계속됩니다최초의 인수에 상대적인 형태로벤더 드롭은 거기에 임포트 됩니다. 마지막에 3번째의 인수는 임포트 하는 로컬 디렉토리입니다. 전의 예를 사용하면(자), 전형적인svn_load_dirs.pl의 실행은 이런 기분이 듭니다:

$ svn_load_dirs.pl http://svn.example.com/repos/calc/vendor/libcomplex \
                   current                                             \
                   /path/to/libcomplex-1. 1

-t 옵션에 태그 명칭을 지정해, 새로운 벤더 드롭 (을)를 태그 짓고 하도록(듯이)svn_load_dirs.pl 에 지시하는 것이 할 수 있습니다.

$ svn_load_dirs.pl -t libcomplex-1. 1                                   \
                   http://svn.example.com/repos/calc/vendor/libcomplex \
                   current                                             \
                   /path/to/libcomplex-1. 1

svn_load_dirs.pl를 실행할 때, 그것은 벌써 존재하고 있는"현재의"벤더 드롭의 내용을 조사해 그것을 지정된 새로운 벤더 드롭의 내용과 비교합니다. 간단한 경우, 다른 한쪽의 버전에 있어 이제 한편에는 없는 것 같은 파일은 없는 구로, 스크립트는 새로운 임포트를, 특히 문제 없게 실행합니다. 그러나, 만약, 버전간에 파일 레이아웃에 차이가 있는 경우, svn_load_dirs.pl 는 이 차이를 어떻게 해결할까 물어 옵니다. 예를 들어, libcomplex의 버전 1.0으로math.c (이었)였던 파일은 libcomplex1. 1에서는arithmetic.c 에 명칭 변경이 된 것을 알고 있는 것을 스크립트에 가르쳐 주는 것이 할 수 있습니다. 이동에 의해 설명할 수 없는 것 같은 차이점은, 통상의 추가와 삭제로서 다루어집니다.

그 스크립트는 또 저장소(repository)에추가되고 있다 정규 표현에 성냥 하는 것 같은 파일과 디렉토리의 속성을 설정한다 위해(때문에), 다른 설정 파일을 받아들일 수가 있습니다. 이 설정 파일은svn_load_dirs.pl 로 -p 옵션을 사용해 지정됩니다. 설정 파일의 각 행은 두 개에서 네 개의 공백에서 단락지어진 값입니다: 추가된 패스에 대해서 성냥 시키는 Perl 스타일의 정규 표현, 제어 키워드(break 또는 cont), 그리고, 옵션으로 속성명과 속성치가 옵니다.

\. png$              break   svn:mime-type   image/png
\. jpe? g$            break   svn:mime-type   image/jpeg
\. m3u$              cont    svn:mime-type   audio/x-mpegurl
\. m3u$              break   svn:eol-style   LF
. *                  break   svn:eol-style   native

추가된 패스 마다, 정규 표현이 패스에 성냥 하는 것 같은 속성 변경 하지만 이 순서로 적용됩니다. 다만 제어의 지정이break (이)가 아닌 경우에 그렇게 됩니다(이것은 그 이상의 속성 변경은 이 패스에 행하지 않는 것을 의미하고 있습니다). 만약 제어 지정이cont continue의 생략형입니다만의 경우는 매칭 처리는 설정 파일의 다음의 행에 이어 갑니다.

정규 표현중의 모든 공백, 속성명, 속성치는 싱글 또는 더블 쿼츠 그리고 묶을 필요가 있습니다. 공백을 둘러싸기 위해서(때문에) 이용하고 있는 것은 아니다 쿼츠 캐릭터는 backslash 캐릭터(\)를 앞에 두고 붙인다 일로 이스케이프 할 수 있습니다. backslash는 설정 파일을 해석할 때 사나워지고 쿼츠 하므로, 정규 표현중에서 필요한 것 이외외의 캐릭터에는 사용하지 말아 주세요.