저장소의 최신 리비전을 작업 사본으로 가져와 같은 리비전으로 변경됩니다.
주로 커밋전에 사용되기도 하고, update로 변경될 사항들을 svn st -u 명령으로 미리 확인할 수 있습니다.

update
usage : update [PATH...]

저장소에 변경된 작업물들을 작업 사본으로 가져옵니다.
리비전을 지정하지 않으면 최신(HEAD)의 리비전을 가져옵니다.
또한 특정 리비전(-r)으로 작업 사본을 동기화 시킬수도 있습니다.

업데이트 된 각 작업물들의 앞에는 알파벳 한 문자로 출력됩니다.
A 추가됨(Added)
D 삭제됨(Deleted)
U 갱신됨(Updated)
C 충돌함(Conflict)
G 합쳐짐(merGed)
E 존재함(Existed)

첫번째 컬럼의 문자는 실제 파일이 변경됨을 뜻합니다.
두번재 컴럼의 문자는 파일의 속성에 대한 변경을 뜻합니다.
세번째 컬럼에 B 는 잠긴 파일이 깨지거나(Broken) 사라졌음(Stolen)을 뜻합니다.

txt.c(A) 파일은 작업 사본에는 없었지만 저장소에 추가된 파일이라 가져왔습니다.
txt.h(D) 파일은 작업 사본에는 있었지만 저장소에서 삭제된 파일이라 작업 사본에서도 삭제되었습니다.
ext.c(U) 파일은 저장소의 내용으로 작업 사본이 갱신되었습니다.
abc.c(G) 파일은 작업 사본에서 수정한 파일이지만 저장소에 수정된 부분과 겹치지 않아서 파일 내용에 알맞게 합쳐졌습니다.
bar.c(C) 파일은 작업 사본에서 수정한 부분과 저장소에서 수정된 부분이 겹쳐져서 충돌이 생겼습니다.

충돌(C)을 제외한 나머지 상태들은 크게 신경쓸게 없지만, 충돌의 경우 약간 작업이 필요합니다.
누군가 커밋한 파일을 업데이트 받지 않고 해당 파일의 겹치는 부분을 수정하여 커밋하려 할 때 커밋 실패 메시지가 출력됩니다.

이 때는 최신 리비전으로 update 해야 하며 update할 때는 충돌을 예상할 수 있습니다.

충돌 메시지가 나타나며 진행 방법을 선택할 수 있습니다.
충돌이 발생한 원본 파일(위에서는 test.txt)에는 충돌에 대한 내용이 포함되어 있습니다.
(df) 는 충돌이 발생한 부분을 확인할 수 있습니다.
확인 후에 (e) 로 편집기를 열어 바로 수정할 수 있습니다.
수정 후에는 (r) resolved 옵션이 추가되는데 편집기에서 충돌을 정상적으로 해결했다면 (r) 입력하여 해결할 수 있습니다.
무조건 내 작업물을 남기려면 (mc)를 입력하고 커밋을 하면 저장소에 본인의 작업물로 갱신됩니다.
당장 해결할 수 없는 문제라면 (p) 버튼을 눌러 파일을 충돌 상태(C)로 남기며 update를 완료합니다.
postpone 이 선택되면 file, file.mine, file.r21, file.r22 등 3개 파일이 더 생성됩니다.
(p)가 아닌 (r)을 입력하면 원본 파일을 제외한 *.mine, *.r21, *.r22 등의 파일들은 생성되지 않으며 상태는 G(merGe) 상태가 됩니다.
머지 상태는 두 버전의 내용이 절충되어 충돌이 해결된 상태라고 생각하면 됩니다.
고장날 일 없으니 각 옵션 별로 테스트를 해보면 이해가 빠를 겁니다.

file.r21 은 마지막으로 저장소에서 받은 file 원본
file.mine 은 r21을 작업 사본에서 수정한 file 작업물
file.r22 는 저장소의 최신 file 작업물
file 은 r21 원본위에 충돌난 부분이 <<<<<< .mine ======== >>>>>>> .r22 등으로 표시

작업자와 상의하여 파일을 합친 후 생성된 3개 파일을 삭제하고 커밋하여 충돌을 해결합니다.

내 작업 사본의 파일/디렉토리의 상태를 나타내는 명령입니다.
update 명령으로 저장소의 작업물과 동기화 시킨 직후라면 status 명령은 아무 값도 리턴하지 않습니다.
저장소와 내 작업 사본의 내용이 동일하기 때문입니다.
update 이후에 저장소에 변경된 작업물이 있는지, 혹은 update 이후에 내 작업 사본에 변경된 작업물이 있는지를 확인할 수 있습니다.
결국 status 명령은 저장소와 내 작업 사본의 작업물과의 동일하지 않은 파일 및 디렉토리를 알려줍니다.
특정 파일 및 디렉토리가 추가되었는지 변경되었는지 삭제되었는지 충돌하였는지 등을 알 수 있습니다.

status (st)
usage : svn status(st) [PATH...]

작업 사본(working copy)의 모든 파일/디렉토리들의 상태를 나타냅니다.
-v 옵션은 모든 파일에 대해 리비전 정보까지 나타냅니다.
-q 옵션은 작업 사본에서 변경된 작업물만 나타냅니다.(? 마크의 작업물은 나타나지 않음)
-u 옵션은 작업 사본 작업물들의 현재 리비전과 저장소의 최신 리비전을 알 수 있고 최신 리비전과 내용이 다른 작업물은 * 마크로 확인이 가능합니다.

파일 한개를 생성하고 커밋하고 다시 수정하고 다시 커밋하는 예를 status 명령으로 상세히 보겠습니다.

* 출력된 작업물 상태 설명 라인의 마크 설명

위 예에서 처럼 상태를 나타내는 마크는 7칸에 걸쳐 나타날 수 있습니다.
작업시에는 보통 첫번째 컬럼의 마크를 자주 보게 됩니다.

1. 첫번째 7컬럼 중 첫번째 컬럼 : 작업물이 추가되거나, 삭제되거나, 다른 변경이 있는지 여부
' ' 변경 없음
'A' 추가되었음(Add)
'C' 충돌했음(Conflicted)
'D' 삭제됐음(Deleted)
'I' svn:ignore 로 무시된 작업물
'M' 변경됐음(Modified)
'R' 교체됐음(Replaced)
'X' svn:externals 로 지정된 외부 관리 대상인 디렉토리
'?' 버전관리 대상이 아닌 작업물
'!' 불안전한 파일이거나 버전관리 대상이지만 svn 명령어를 사용하지 않고 삭제되었음.
'~' 저장소와 작업 사본에 이름은 같지만 다른 타입의 개체로 존재함. (파일-디렉토리).

2. 두번째 컬럼 : 작업물 속성의 변경 여부
' ' 변경 없음
'C' 충돌했음(Conflicted)
'M' 변경됐음(Modified)

3. 세번째 컬럼 : 작업 사본 디렉토리가 잠겼는지 여부
' ' 잠기지 않았음
'L' 잠겼음(Lock)

4. 네번째 컬럼 : 과거의 커밋로그를 포함하여 전송될 예정인지 여부
' ' 과거의 커밋로그를 포함하지 않음
'+' 과거의 커밋로그를 포함

5. 다섯번째 컬럼 : 작업물이 전환되거나 외부 파일인지 여부
' ' 기본 작업물
'S' branches 나 tags 로 전환된 작업물임
'X' svn:externals 지정으로 생성된 버전관리 파일임

6. 여섯번째 컬럼 : 저장소 잠금 토큰
' ' 잠금 토큰 아님
'K' 잠금 토큰 존재(toKen)
-u 옵션 사용시
' ' 저장소가 잠기지 않았고, 잠금 토큰도 아님
'K' 저장소가 잠겼고, 잠금 토큰 존재
'O' 저장소가 잠겼고, 다른(Other) 작업 사본에 잠금 토큰 존재
'T' 저장소가 잠겼고, 잠금 토큰이 존재하지만 사라짐(sTolen)
'B' 저장소가 잠기지 않았고, 잠금 토큰은 존재하지만 깨졌음(Broken)

7. 일곱번재 컬럼 : 구조(tree)의 충돌로 영향을 받은 작업물인지 여부
' ' 기본 작업물
'C' 트리 충돌 (다음 행에 충돌에 대한 부연 설명 출력)
아홉번째 컬럼 : 최신 리비전 여부 (-u 옵션 사용시)
' ' 최신 리비전
'*' 저장소에 새로운 리비전이 존재

new.c(?) 새로 생성되었고 버전관리 대상이 아닙니다. commit 에도 영향을 받지 않으며 버전관리 하기 위해서는 add 후 commit 하면 됩니다. ?를 가진 파일이 많다면 status 명령시 -q 옵션으로 ? 파일들은 출력되지 않게 할 수 있습니다.
txt.c(!) 버전관리 대상이지만 svn del 명령이 아닌 삭제나 이동등으로 파일이 존재하지 않습니다. revert로 복구합니다.
bar.c(M) 두번째 컬럼이므로 파일 속성이 변경되었음을 뜻합니다. 예로 동일한 파일명이지만 덮어씌워지거나 하여 원래의 속성의 파일이 아닌 경우 발생합니다. commit 시 저장소에 적용됩니다.
foo.c(*) 최신 리비전에 변경 사항이 있는 파일입니다. update시 최신 리비전의 변경사항을 저장소에서 작업 사본으로 가져옵니다.
del.c(D) 작업 사본에서 삭제가 예약된 파일입니다. commit 시 저장소에서도 삭제됩니다.
qax.c(A+) svn copy나 move 등으로 새로 생성되었고 기존 파일의 히스토리도 가지고 있는 파일입니다. commit 시 저장소에도 추가됩니다.
session(I) 저장과 삭제가 반복되는 session 디렉토리나 temp_image 디렉토리 같은 경우는 버전관리 대상이지만 svn:ignore 옵션으로 무시합니다. 무시하지 않는다면 session 디렉토리에 생성되는 무수히 많은 세션관련 파일들이 ?로 나타날 것입니다.

작업 사본에서 버전 관리 대상인 작업물들을 추가/수정/삭제한 뒤.
작업 사본의 현재 상태를 저장소에 덮어 씌우는 것이 바로 commit 작업 입니다.
commit 하기 전에는 항상 update 명령을 사용하여 작업 사본을 저장소의 최신 정보로 동기화 시킨 후에 사용합니다.

예를 들어 저장소에 index.php 파일이 있고 그 안에는 a = b + c 라는 내용이 있습니다.
A씨가 자신의 작업 사본에서 index.php 파일의 내용을 a = b * c 라고 수정하였습니다.
그리고 B씨가 자신의 작업 사본에서 index.php 파일의 내용을 a = b / c 라고 수정하였습니다.
A씨가 먼저 커밋을 했다고 칩시다. 아마 정상적으로 커밋은 완료되었을 것이고 리비전은 1 올랐을 것입니다.
이 상황에서 B씨가 커밋을 시도한다면 충돌(C)이 날 것입니다.
저장소 상에는 index.php 파일의 a = b + c 부분이 A로 인해 a = b * c 로 수정되어 있기 때문에,
B가 만약 index.php 파일을 덮어 씌운다면 A가 작업한 내용은 사라지게 됩니다.
그렇기 때문에 한번 확인하고 커밋하라는 의미에서 svn 은 친절하게 충돌(C)이라고 알려줍니다.

그래서 커밋 전에는 update 명령을 습관적으로 실행하는 것이 좋습니다.
위 상황이라면 update도 충돌나는 것은 마찬가지 입니다.
B씨가 index.php 파일을 수정 후 커밋전 update 명령을 실행했을 때 A씨가 이미 커밋을 했다면,
A씨가 변경한 a = b * c 내용을 B씨의 index.php 파일에 덮어 쓰려고 시도하겠지만,
B씨 역시 a = b / c 로 내용을 변경했으므로 충돌(C)이 발생합니다.
충돌이 났을 경우 누구의 것을 살릴지는 내용을 확인하고 수정하면 해결 됩니다.
충돌을 해결하는 부분은 뒤에 update 명령이나 resolve 명령을 통해 자세히 알아 보겠습니다.

commit (ci)
usage : commit [PATH...]

작업 사본에서 변경된 작업물들을 저장소로 보냅니다.
Log 메시지는 -m 또는 -F 옵션을 이용해서 반드시 전달되야 하며, 냉무도 가능합니다.
메시지를 전달하지 않는다면 지정된 편집기가 시작될 것입니다.
저장소에 잠김 파일이 포함되어 있을 경우, 커밋이 정상적으로 이루어 진다면 잠김은 해제될 것입니다.
PATH를 지정하지 않으면 현재 위치에서 하위 디렉토리를 포함해서 변경된 모든 파일을 커밋합니다.
커밋이 완료되면 새로운 revision 번호(기존 revision + 1)가 생성됩니다.

delete 명령으로 지정된 경로의 작업물을 삭제할 수 있습니다.
버전 관리 중인 파일 혹은 디렉토리를 svn 명령어를 사용하지 않고 그냥 삭제 해버린다면,
없어져 버렸다면 status 에서 해당 파일에 대해 느낌표(!)를 감상하실 수 있습니다.

delete (del, remove, rm)
usage : svn rm PATH(URL)...

PATH로 지정된 모든 작업물을 다음 commit 시 삭제하도록 예약합니다.
파일이나, commit 된 적이 없는 디렉토리는 작업 사본에서 즉시 삭제됩니다.
PATH에 버전관리 대상이 아니거나(?) 수정된(M) 작업물이 포합되어 있으면 --force 옵션을 사용해야 삭제될 것입니다.

이번에는 작업 사본에서 add 명령을 통해 파일을 저장소로 커밋하는 방법을 알아보겠습니다.
작업 사본이 생기면 기존 파일을 수정하거나, 새로운 파일을 생성할 것입니다.
작업 사본에서 새로 생성한 파일의 존재는 저장소에서 알 수 없습니다.
그것은 바로 add 명령으로 버전 관리 대상으로 추가하고, commit 명령으로 저장소로 전송하고 나면 버전 관리가 가능해 집니다.

add
usage : svn add PATH...

새로 생성된 파일이나 디렉토리를 작업 사본 상에서 버전 관리 대상으로 추가 합니다.
다음 commit 시에 저장소에 추가됩니다.
추가할 파일이 많을 때에는 한칸의 공백으로 구분이 가능하고 /* 등의 와일드카드 표기도 가능합니다.

예를 들어 txt.c 라는 새로운 파일을 생성합니다.
svn st(status)는 파일의 상태를 묻는 명령입니다. 상태가 물음표(?) 라는 것은 "이 파일 뭐냐?" 란 뜻입니다.
버전 관리 대상이 아닌 파일이 작업 사본에 있으므로 물음표(?) 라는 상태가 나타난 것입니다.

svn add 명령으로 txt.c 파일을 버전 관리 대상으로 추가하고
svn st(status) 명령으로 txt.c 파일의 상태가 A(add) 추가되었음을 알 수 있습니다.
하지만 commit 명령을 내리기 전까지 저장소는 이 파일의 존재를 모릅니다.

commit 명령으로 txt.c 파일을 커밋하고 새로운 리비전(3)을 얻게 되었습니다.

add 명령으로 여러 파일을 추가하고자 할 때는,

등으로 띄어쓰기로 파일들을 구분하여 명시가 가능하며

등으로 버전 관리 대상이 아닌 모든 파일을 버전 관리 대상으로 추가 하는 방법이 있습니다.