'Tool/Subversion'에 해당하는 글 17건

svn update

Tool/Subversion 2012. 10. 30. 23:52

저장소의 최신 리비전을 작업 사본으로 가져와 같은 리비전으로 변경됩니다.
주로 커밋전에 사용되기도 하고, 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)을 뜻합니다.

 

$ svn up
A    txt.c
D    txt.h
U    ext.c
G    abc.c
C    bar.c
Updated to revision 10.

 

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

 

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

 

$ svn ci -m 'modify by oops4u' test.txt
svn: Commit failed (details follow):
svn: File or directory 'test.txt' is out of date; try updating
svn: resource out of date; try updating

 

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

 

$ svn up
Conflict discovered in 'test.txt'.
Select: (p) postpone, (df) diff-full, (e) edit, (r) resolved,
        (mc) mine-conflict, (tc) theirs-conflict,
        (s) show all options:

 

충돌 메시지가 나타나며 진행 방법을 선택할 수 있습니다.
충돌이 발생한 원본 파일(위에서는 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개 파일을 삭제하고 커밋하여 충돌을 해결합니다.


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

svn status

Tool/Subversion 2012. 10. 29. 22:05

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

 

 

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

 

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

 

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

 

$ svn up
At revision 10.
// 동기화 후 현재 리비전 출력.

$ svn st
// 아무변화 없음. 저장소와 작업물이 동기화 된 상태이므로.

$ cat > test.txt
// 파일 생성 후

$ svn st
?        test.txt
// 작업 사본 영역에 버전 관리 대상이 아닌 것(?)이 있음.
// 이 상태에서는 test.txt 를 커밋하려 해도 커밋이 되지 않습니다. 버전 관리 대상이 아니기 때문에.
// 다시 update 명령을 날린다 해도 변화는 일어나지 않습니다. 버전 관리 대상이 아니기 때문에.
// 상태가 물음표(?)인 파일을 버전 관리 대상으로 만들기 위해서 add 명령이 있습니다.

$ svn add test.txt
A        test.txt
// 버전 관리 대상으로 예약 되었다는 상태(A:Add)가 표시됩니다.
// 이 상태에서 update 명령을 사용하면 저장소에는 test.txt 파일이 없기 때문에 작업 사본에서도 지워질까요?
// 작업 사본 영역의 상태들은 예약임을 뜻합니다. 아직까지는 작업 사본에서만의 버전 관리 대상입니다.
// 저장소는 이 파일(text.txt)의 존재를 모르므로 지워지지 않습니다.

$ svn ci -m 'add test.txt by oops' test.txt
Sending        test.txt
Transmitting file data .
Committed revision 11.
// 커밋으로부터 리비전이 1증가하게 됩니다.
// 커밋하기 전에 다른 사용자가 몇번의 커밋을 사용하여 리비전이 이미 증가되고 업데이트된 작업물이 있을 수 있으니
// 커밋 전에는 항상 update 명령을 사용하는 습관을 들입니다.

$ svn up
At revision 11.
$ svn st
// 저장소와 내 작업 사본의 최신 리비전인 11 에서 변경된 작업물이 없으므로 아무 것도 출력되지 않습니다.

 

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

 

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

 

$ svn st
?______ test.txt

 

 

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 옵션 사용시)
' ' 최신 리비전
'*' 저장소에 새로운 리비전이 존재

 

$ svn st -u wc
?                   wc/new.c
!            965    wc/txt.c
 M           965    wc/bar.c
       *     965    wc/foo.c
D            965    wc/del.c
A  +         965    wc/qax.c
I            965    wc/session
Status against revision:   981

 

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 디렉토리에 생성되는 무수히 많은 세션관련 파일들이 ?로 나타날 것입니다.


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  8개가 달렸습니다.
  1. 레어티즈 2012.11.05 14:11
    안녕하세요. 글 잘봤습니다.
    기존에 체크아웃 받았던 프로젝트에서 root계정으로 update를 받고 다른계정으로 svn status 를 해보니 동일한 폴더의 파일들인데 버전관리 대상이 아니라고 나타나네요..
    이런 경우 add 시킨 후에 commit을 시키면 기존 svn에 있는 내용들에 영향을 미치는지 궁금하네요.
    • 음... 정확한 요지를 파악하지 못했지만...
      1. root 계정과 혼용하면 소유자 접근 권한 때문에 작업이 원활하지 않을 겁니다. 이미 사용중이시지만 비추입니다.
      2. 동일한 폴더의 파일들인데 버전관리 대상이 아니라고 당연히 나올 수 있습니다. 마지막 commit/update 후에 새로 생성 되었고 add/commit 하지 않은 파일들 입니다. 이미 버전관리 대상인 디렉토리와는 별개입니다.
      3. 어쨌든 버전관리 대상이 아닌파일(?)을 add 후에 commit 하려 할때 충돌여부는... 저장소 안에 동일한 파일명이 존재하지 않으면 충돌하지 않습니다.
    • 레어티즈 2012.11.05 20:48
      음..... 그러면 다시 질문 드리면요..
      /A/b.txt 경로의 b.txt파일을 root계정으로 update를 받았습니다.
      다른계정으로 로그인하여
      위와같이 동일한 /A/b.txt 경로의 b.txt파일을 svn에서는 다른파일로 인식될 수 있나요?
      업데이트를 하려고 하면 "버전관리 되지 않은 같은 이름의 디렉토리가 이미 존재합니다." 라고 나오네요..
    • 질문으로 예상컨데,
      저장소에 /A/b.txt 가 있고
      AA라는 작업사본에 root 계정으로 b.txt 파일을 update 했고.
      BB라는 작업사본에 다른 계정으로 b.txt 파일을 update 하려는데
      "버전관리 되지 않은 같은 이름의 디렉토리"가 존재한다는 말씀이신가요?

      그렇다면 말그대로 BB라는 작업사본에서 svn st 로 물음표(?)뜨는 파일 혹은 디렉토리 중에
      이미 저장소에 있는 파일/디렉토리와 동일한 파일(버전관리 되지 않은)이 있기 때문입니다.
      이 경우 작업사본의 파일이 최신이라면 svn del svn:// 등으로 저장소 파일을 삭제하고,
      BB 작업사본의 파일을 add/commit 하면 될 것이구요.
      반대로 저장소의 파일이 최신이라면 물음표(?) 파일들을 강제 삭제하고 update 받으시면 됩니다.
    • 레어티즈 2012.11.06 10:07
      답변 감사합니다.
      만약 저장소 파일을 삭제하고 add후 commit을 시키면 기존 Revision은 모두 삭제 되는게 맞지 않나요..?
      현재 실제 운영하고 있는 서버이다보니 양쪽다 최대한 변경 안되는쪽으로 해보려고 방법을 찾고있거든요.
    • 리비전은 삭제되지 않습니다. 저장소에 변경을 가할때마다(commit 등) +1 증가합니다.
      리비전이 삭제된다면 버전 관리 프로그램을 사용할 이유가 없습니다.

      어떻게 네트워크가 구축되어 있으신지는 모르겠지만,
      real server 에서는 일반적으로 저장소로부터 update만 받습니다.
      그리고 작업사본에서는 저장소와 지지고 볶고 수정하거나 추가해야 할 모든 것들에 대한 작업을 합니다.
      올리고 내리고 완벽하게 테스트 한 후 commit.
      real server 에서는 update.

      이렇게 하면 real server 에는 충돌 이나 이상 현상이 나타날 가능성은 거의 없습니다.
    • 레어티즈 2012.11.07 08:28
      덕분에 몇일동안 끙끙 앓던걸 해결했네요..^^;
      문제가 나타났던 디렉토리들을 백업시켜놓고 새로 update 받으니 정상적인 상태로 돌아오네요..
      느낌표가 떠서 약간 움찔했지만 글 써놓으신대로 revert 시키니 문제 없네요^^
      친절히 답변 해주셔서 감사합니다^^
      좋은 하루 되세요~
    • 도움이 되셨다니 다행입니다. 좋은 하루 보내세요~!
secret

svn commit

Tool/Subversion 2012. 10. 24. 00:30

작업 사본에서 버전 관리 대상인 작업물들을 추가/수정/삭제한 뒤.
작업 사본의 현재 상태를 저장소에 덮어 씌우는 것이 바로 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)가 생성됩니다.

 

$ svn ci -m 'modify index by ggamzzak' index.php
Sending        index.php
Transmitting file data .
Committed revision 5.
# -m 옵션을 사용하여 리비전 메시지와 함께 index.php 파일을 커밋합니다.


$ svn log -r 5 -v
------------------------------------------------------------------------
r5 | ggamzzak | 2012-10-23 23:10:09 +0900 (Wed, 24 Oct 2012) | 1 line
Changed paths:
   M /trunk/index.php
modify index by ggamzzak
------------------------------------------------------------------------
# 리비전 메시지는 log 명령으로 확인할 수 있습니다.

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

svn delete

Tool/Subversion 2012. 10. 23. 23:30

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

 

 

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

 

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

 

$ ls
txt.c
# 현재 작업 사본에는 txt.c 파일이 있습니다.


$ svn del txt.c
D       txt.c
# svn del 명령을 사용하여 다음 커밋시에 txt.c 파일이 삭제(D)되도록 예약합니다.


$ ls
# 작업 사본에서는 이미 삭제 되어 있습니다.


$ svn st txt.c
D       txt.c
# status(st) 로도 D(delete) 상태를 보고 삭제 예약이 되어 있음을 확인할 수 있습니다.


$ svn ci -m 'del txt.c' txt.c
Deleting     txt.c
Transmitting file data .
Committed revision 4.
# 커밋으로 txt.c 파일의 삭제를 저장소와 동기화하고 새로운 리비전(4)이 생성되었습니다.


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

svn add

Tool/Subversion 2012. 10. 22. 23:30

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

 

 

add
usage : svn add PATH...

 

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

 

$ vi txt.c
$ svn st txt.c
?       txt.c

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

 

$ svn add txt.c
A       txt.c
$ svn st txt.c
A       txt.c

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

 

$ svn ci -m 'add txt.c' txt.c
Sending      txt.c
Transmitting file data .
Committed revision 3.

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

 

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

$ svn add txt1 txt2 txt3

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

$ svn add *

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


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret