The error message you're encountering indicates that there's an issue with a Git Large File Storage (LFS) object that is preventing your push to GitLab. Specifically, a file (AI/pyvideotrans-main/ffmpeg/you-get.exe) is marked as missing in the LFS, which is causing the push to fail. Here's how you can address this issue:

1. Verify LFS Objects: First, ensure that all the necessary files are tracked and uploaded correctly in LFS. You can list LFS objects that are supposed to be uploaded with:이you-get.exe file or any other files are indeed missing or incorrectly tracked.
2. bashCopy code
   git lfs ls-files
3. Check for Missing Files: If the you-get.exe file is missing from your local repository, you'll need to obtain it again. This could mean downloading it from a source or finding the correct version of the file that should be there.
4. Re-upload LFS Objects: After you've added or corrected the file in your local repository, you'll need to re-upload the LFS objects. You can do this with:
5. bashCopy code
   git lfs push --all origin
6. Consider LFS Locking: The message about LFS locking is a suggestion for managing LFS files, especially in a team environment. Enabling LFS file locking can prevent accidental overwrites when multiple people are working with large files. You can enable it with:
7. bashCopy code
   git config lfs.https://gitlab.com/swteam3/SuperWorldTTS.git/info/lfs.locksverify true
8. Retry Pushing: Once you've addressed the missing file and re-uploaded the LFS objects, try pushing to the repository again:
9. bashCopy code
   git push origin
10. Consider allowincompletepush Option: As a last resort, if you're certain that the missing LFS object is not critical and you need to push the other changes, you can disable the check that's causing the push to fail. However, this should be used with caution as it can lead to incomplete data in your repository:
11. bashCopy code
    git config lfs.allowincompletepush true git push origin

Remember, it's important to resolve these issues correctly to ensure that your repository remains consistent and all necessary files are available for you and your team.

Currently working custom merge options for WinMerge:

The options I used in Sourcetree 3.4.3 for Windows 64-bit with WinMerge 2.16.10.0 x64 and which worked for merging:

• Options > Diff > External Diff / Merge:
  • Merge Tool: Custom
  • Merge Command: C:\Program Files\WinMerge\WinMergeU.exe
    • Arguments:

      -wl -wr -dl Remote -dm Base -dr Local \"$REMOTE\" \"$BASE\" \"$LOCAL\" -o \"$MERGED\"

ref : https://jira.atlassian.com/browse/SRCTREEWIN-13514

커밋...을 클릭하시면

아래와 같이 화면이 나오는데

검색하고자 하는 Commit 번호와 확인 버튼을 클릭하시면 됩니다.

ref : https://organizingdata.tistory.com/96

병합 요청(MR)은 한 브랜치를 다른 브랜치로 병합하기 위한 요청이다. 병합 요청을 사용하여 소스 코드에 대해 제안된 변경사항을 시각화하고 협업한다.

개요

• 병합 요청(일명 "MR")은 제안된 변경사항에 대한 많은 정보를 표시한다. MR의 본문에는 위젯(CI/CD 파이프라인이 있는 경우, 관련 정보 표시)과 함께 설명이 포함되며, 그 뒤에 해당 MR로 협업하는 사람들의 토론 스레드가 표시된다.
• MR에는 스레드에서 발생하는 토론, 커밋 목록, 파이프라인 및 Job 목록, 코드 변경 및 인라인 코드 리뷰를 볼 수 있는 내비게이션 탭도 포함되어 있다.

사용 사례

A. 팀에서 일하는 소프트웨어 개발자일 경우

1. 새 브랜치를 체크아웃하고 병합 요청을 통해 변경사항을 제출한다.
2. 팀에서 피드백을 수집한다.
3. 코드 품질 보고서로 코드를 최적화하는 구현 작업을 수행한다.
4. GitLab CI/CD의 단위 테스트 보고서로 변경사항을 검증한다.
5. 라이선스 준수 보고서를 통해 라이선스가 프로젝트와 호환되지 않는 종속성을 사용하지 않도록 한다. (ULIMATE)
6. 관리자에게 승인을 요청한다. (STARTER)
7. 관리자 :
   a. 최종 리뷰와 함께 커밋을 푸시한다.
   b. 병합 요청을 승인한다. (STARTER)
   c. 파이프라인이 성공하면 병합되도록 설정한다.
8. 변경사항은 GitLab CI/CD에 대한 수동 작업을 통해 프로덕션에 배포된다.
9. 구현이 성공적으로 고객에게 전달된다.

B. 회사의 웹 사이트를 위한 웹페이지를 작성하는 웹 개발자일 경우

1. 새 브랜치를 체크아웃하고 병합 요청을 통해 새 페이지를 제출한다.
2. 리뷰어(Reviewers)로부터 피드백을 수집한다.
3. Review Apps로 변경사항을 미리 볼 수 있다.
4. 웹 디자이너에게 구현을 요청한다.
5. 관리자에게 승인을 요청한다. (STARTER)
6. 승인되면, 병합 요청이 스쿼시(Squash) 및 병합되고, GitLab Pages를 사용하여 스테이징(Staging)에 배포된다.
7. 프로덕션 팀이 프로덕션으로 병합 커밋을 체리 픽(Cherry-pick) 한다.

상단의 병합 요청 내비게이션 탭

• 병합 요청에 대한 설명을 포함하는 새 Overview탭이 병합 요청의 맨 위에 위치한다. Overview 옆에서 Commits, Pipelines 및 Changes를 찾을 수 있다.

Merge Request 만들기

• 모든 병합 요청은 브랜치를 만드는 것으로 시작된다. Git CLI 애플리케이션을 통해 명령 줄로 로컬에서 수행하거나 GitLab UI를 통해 할 수 있다.
• 새 병합 요청을 시작하면, 방법에 관계없이, New Merge Request 페이지로 이동하여 병합 요청에 대한 정보를 채운다.
• 방법에 관계없이 새 브랜치를 GitLab에 푸시하면, Create Merge Request 버튼을 클릭하고 거기에서 병합 요청을 시작한다.

New Merge Request 페이지

• New Merge Request 페이지에서, 병합 요청에 대한 제목과 설명을 작성하여 시작한다. 브랜치에 이미 커밋이 있는 경우 제목은 첫 번째 커밋 메시지의 첫 번째 라인으로 미리 채워지고, 설명은 커밋 메시지의 추가 라인으로 미리 채워진다. 제목은 모든 경우에 필수인 유일한 필드이다.
• 여기에서, 정보(제목, 설명, 담당자, 마일스톤, 레이블, 승인자)를 입력하고 Create Merge Request 버튼을 클릭할 수 있다.

Create Merge Request 버튼

• 새 브랜치를 GitLab에 푸시했으면, GitLab의 저장소를 방문하여 화면 상단에서 Create Merge Request 버튼을 클릭할 수 있는 call-to-action(CTA, 행동 유도 또는 클릭 유도)을 확인한다.

ref : https://velog.io/@leyuri/Gitlab-Merge-Request-%EA%B8%B0%EB%8A%A5%EC%9D%B4%EB%9E%80

TortiseSVN 툴을 사용 중, 갑자기 제목과 같은 오류가 발생했습니다.

웃기는 일이 아닐 수 없습니다. Clean up 하래서 Clean up 을 했더니, 오류가 나고 다시 Clean up 을 하라고 합니다.

문제상황

SVN Update 를 하려고 할 때 아래와 같은 오류가 발생하였습니다.

에러메세지

Previous operation has not finished; run 'cleanup' if it was interrupted

그래서 Clean Up 을 하려고 하니 아래와 같은 오류가 다시 발생하였습니다.

에러메세지

Cleanup failed to process the following paths:

Previous operation has not finished; run 'cleanup' if it was interrupted

Please execute the 'Cleanup' command.

해결방법

http://www.sqlite.org/download.html

위 링크로 접속한 후에 sqlite-tools-OS버전 으로 된 첨부 URL 을 다운받은 후 압축해제합니다. (저의 경우는 윈도우)

압축을 해제하면 sqlite3 이라는 exe 파일이 있는데, 이 파일을 SVN 홈 경로로 이동시킵니다.

이 후 CMD 창을 통해서 SVN 경로로 이동한 후에 다음과 같은 명령어를 수행합니다.

sqlite3 .svn/wc.db "select * from work_queue"

위와 같이 쿼리를 날리는 이유는, TortiseSVN 이 형상관리를 위해 SQL DB 를 사용하기 때문입니다.

큐에 있는 대상이 출력되면 해당 출력은 DELETE 합니다.

큐에 있는 파일을 삭제하는거지 실제로 물리적 파일이 삭제되는게 아니기 때문에 걱정하지 않으셔도 됩니다.

sqlite3 .svn/wc.db "delete from work_queue"

이렇게 큐에서 삭제한 후에 다시 Cleanup 을 수행하니 이번에는 폴더가 Lock 이 되었다는 에러메시지가 나옵니다..

에러메세지

Cleanup failed to process the following paths

FOLDER Working copy FOLDER locked.

FOLDER is already locked.

Please execute the 'Cleanup' command.

이번에는 락에 있는 폴더 대상을 삭제시켜 줍니다.

마찬가지로 물리적 삭제가 아니기 때문에 안심하셔도 됩니다.

sqlite3 .svn/wc.db "delete from wc_lock"

이제는 Clean up 이 정상적으로 수행되었습니다.

다시 Add , Update , Commit 등의 작업을 수행할 수 있게 되었습니다.

TortoiseGit 을 설치한다음 git 을 설치 하는데 git 은 다음만 계속 눌러서 설치하면 된다

로그인시 gitlab 의 username 과 pw 를 입력

이 값은 GitLab에서 Profile Settings 메뉴로 들어간 뒤 SSH Keys 항목

으로 들어가 키 내용을 붙여 넣은 후 Add Key하면 등록이 완료됩니다.

단계7. TortoiseGit의 Settings 메뉴에 들어가서 Remote에 기록한 origin 항목에 아까 저장한 private 키 파일을 연결하면 GitLab을 사용할 준비가 모두 완료 되었습니다. 

제가 사용하는 TortoiseGit에는 TortoiseSVN과 다르게 GUI에서 ignore pattern을 제공하지 않습니다.

그래서 무시할 패턴을 작성한 파일을 수동으로 생성해야 합니다.

2가지 방법이 있습니다. ".gitignore" 파일 생성, ".git/info/exclude" 파일 변경
두가지 모두 파일의 내용은 동일합니다.

우선 .gitignore 방식으로 설명합니다.

1, 작업 디렉토리 최상위에 ".gitignore"파일을 생성합니다.
(또는 작업 디렉토리 최상위의 ".git/info/exclude"파일을 오픈합니다.)

2, 위의 파일을 메모장 등으로 엽니다.

3,  원하시는 제외 패턴을 작성하고 파일을 저장 합니다.(끝)

패턴 작성 시 참고사항은

# 이후의 내용은 주석 처리 됩니다.

제가 사용하는 델파이의 무시 패턴은 아래와 같습니다.(.gitignore 파일은 첨부합니다.)

*.dcu

*.~*

*.dproj.local

*.identcache

__history

*.drc

*.map

*.zip

*.exe

*.dll

*.elf

 .gitignore
다른 패턴은 아래 링크를 확인하세요.
https://github.com/github/gitignore  

push 유저 이름 세팅

ref : https://indiegd.blogspot.com/2016/12/tortoisegit-gitlab-ssh-key.html

ref : https://blog.hjf.pe.kr/45

ref : http://osgl.ethz.ch/training/Tutorial_GitLab_Webstorm_TortoiseGit.pdf

git 과 연동하여 소스트리(source tree) 최신버전으로 리소스를 push 하려고 할 때 

아래와 같은 내용이 보인다면 git 에 유저에 대한 tocken 이 추가되어 있지 않기 때문에 발생하는 에러인데

git -c diff.mnemonicprefix=false -c core.quotepath=false push -v --tags origin master:master

Pushing to git@gitlab.com:계정명/프로젝트명.git

remote: GitLab: API is not accessible        

To gitlab.com:계정명/프로젝트명.git

 = [up to date]      ~~~~~ -> ~~~~~~~~~~~~~~~

 ! [remote rejected]   master -> master (pre-receive hook declined)

error: failed to push some refs to 'git@gitlab.com:계정명/프로젝트명.git'

이때는 git 홈페이지에서

Access Tockens -> Personal Access Tockens 페이지에서 

Add a personal access tocken 란에서

Name 과 Expires at  을 각가 채운후 지정하고 싶은  Scopes 를 선택한다음

Create persoan access tocken  을 눌러 접근 토큰을 생성해주면 push 가 가능해진다

다른 부분은 그럭저럭 따라하지만 Generate 한다음 상단 박스부분이

키라는 것이 좀 애매한 부분이라서 직관적으로 와닿지 않는 부분이 있다

정확하게 저장해주면 좋은데 public 키와 상단 박스키의 내용이 앞뒤로 

내용이 약간 다르다

소스트리로 Git SSH 키 사용하기 

Git를 할 때, HTTPS로 하는 것보다는 SSH로 하는 것이 보안상 더 안전합니다.

SSH는 계정 및 암호뿐 아니라 상호간 암호 키를 제출해야 합니다.

또한 모든 전송 데이터가 암호화되며 익명을 사용할 수 없습니다.

아틀라시안의 소스트리를 사용하면 좀 더 수월하게, GUI 환경에서 SSH를 사용할 수 있습니다.

https://www.sourcetreeapp.com/

Free Mercurial and Git Client for Windows and Mac | Atlassian SourceTree

www.sourcetreeapp.com

아틀라시안은 비트버킷이라는 자체 Git 호스트를 운영하고 있지만

소스트리는 어떤 Git에서도 작동합니다.

먼저, SSH를 사용하려면 키쌍을 만들어야 합니다.

소스트리에서 키 생성기를 바로 실행할 수 있습니다.

상단 메뉴의 도구 > SSH Key 생성 또는 불러오기

를 선택합니다.

이것은 

(프로그램 파일)\Atlassian\SourceTree\tools\putty\puttygen.exe

를 실행한 것과 같습니다.

Generate 버튼을 선택합니다.

이때 마우스를 이리저리 움직여줘야 합니다.

(마우스의 움직임이나 위치를 랜덤 시드로 사용하는 모양입니다.)

오른쪽 아래의 Save private key를 선택해서 적당한 위치에 저장합니다.

이 프라이빗 키는 클라이언트 측에서 제출해야 합니다.

상단 읽기 전용 택스트 박스에 나와 있는

ssh-rsa로 시작하는 퍼블릭 키도 따로 복사해서 저장합니다.

퍼블릭 키는 서버 측에서 제출해야 합니다.

프라이빗 키는 

소스트리 상단 메뉴의 도구 > 옵션 > 일반 탭

에서 고를 수 있습니다.

그런데 프라이빗 키를 실제로 제출하는 프로그램은 소스트리가 아니라 Pageant라는 녀석입니다.

시스템 트레이에 이미 실행이 되어 있습니다.

그렇기 때문에 이 변경사항은 즉시 반영이 되지 않고, 소스트리를 재시작해도 반영되지 않습니다.

오른 클릭해서 종료시킨 다음 소스트리를 다시 켜줍니다.

그러면 이 녀석이 소스트리와 함께 자동으로 켜지면서 반영이 될 것입니다.

언제든지 Pageant를 오른 클릭해서 View Keys를 선택하면

키가 제대로 등록되었는지, 어떤 키를 제출하고 있는지를 확인할 수 있습니다.

이제는 퍼블릭 키를 등록할 차례입니다.

퍼블릭 키는 서버가 제출해야 합니다. 즉, 비트버킷이나 기트허브에서 제출해야 합니다.

이를 위해서는 사용자 계정 세팅에서 키를 등록해야 합니다.

각 호스트 사이트에 로그인 한 뒤 개인 설정을 보면 SSH 키 등록 항목이 있습니다.

여기에 아까 복사해뒀던 퍼블릭 키를 등록합니다.

만약 프라이빗 키(ppk)는 있지만 퍼블릭 키를 잃어버렸다면

앞서 사용한 키 생성기의 하단 Load 버튼을 눌러 

프라이빗 키를 불러오면 다시 퍼블릭 키를 볼 수 있습니다.

이제 양쪽에 SSH 키를 등록했으니 SSH로 작업을 할 수 있을 것입니다.

리모트 리포지토리의 프로토콜을 HTTPS에서 SSH로 바꿉니다.

소스트리 상단 메뉴의 저장소 > 저장소 설정 > 원격 탭

에서 수정할 원격 이름 항목을 선택하고 하단의 편집 버튼을 누르면 원격 주소를 변경할 수 있습니다.

그런데 막상 소스트리에서 풀이든 푸시든 해보면 시간이 아무리 지나도 완료가 되지 않습니다.

메시지 창을 펼쳐보면 다음과 같은 메시지가 나옵니다.

The server's host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is.
The server's rsa2 key fingerprint is:
ssh-rsa 2048 aa:d1:aa:00:bb:c0:b0:a0:d0:e0:f0:a0:a1:00:11:ee
If you trust this host, enter "y" to add the key to
PuTTY's cache and carry on connecting.
If you want to carry on connecting just once, without
adding the key to the cache, enter "n".
If you do not trust this host, press Return to abandon the
connection.

최초로 SSH를 사용한 서버의 경우, 등록되지 않은 호스트라면서 이런 메시지가 나타나게 됩니다.

명령 프롬프트를 켜고
(프로그램 파일)\Atlassian\SourceTree\tools\putty
로 이동합니다.

plink.exe (서버 호스트 이름)
을 입력합니다.
예를 들면,
plink.exe github.com

그러면 위와 똑같은 메시지가 나오며, y를 입력해서 진행합니다.
이때, 계정과 암호를 묻는데 굳이 입력하지 않고 엔터를 쳐서 끝내도 됩니다.


이제 정말로 SSH를 소스트리로 쓸 준비가 끝났습니다.
이전과 마찬가지로 작업을 하면 됩니다.

ref : http://donggas90.blog.me/220690109105

http://stackoverflow.com/questions/1265915/how-to-delete-a-workspace-in-perforce-using-p4v

http://vip125.blog.me/220445920670

개발자라면.. SVN을 많이 사용하고 계실겁니다.. 

그런데 SVN 서버를 구축하는 방법을 알고 계신분들은 많을지 모르겠네요..

시작하기전 SVN Server 를 다운로드 받으셔야 됩니다.

https://www.visualsvn.com/server/

VisualSVN Server | Subversion Server for Windows

www.visualsvn.com

▲ 오른쪽 상단에 있는 다운로드를 클릭하시고, 하단 32/64bit 중 택일하여 다운로드 받으시면됩니다. 

▲ 설치를 진행합니다.. Next..

▲ 체크해주시고 Next..

▲ 딱히 다른걸 체크할 필요는 없으니.. 그냥 그대로 Next..

▲ 여기에서 일반적으로 설치 하실때에는 StandardEditon 을 선택하시면 됩니다.

    그리고 경로 설정하신후 Next를 눌러주시면 됩니다. (사진이 빠졌어요 ㅠㅠ)

▲ 그럼 최종적으로 설치가 이루어지고 마무리가 됩니다.

※ 설치가 완료되면 VisualSVN Server 를 실행시켜 줍니다. 

▲ 위와 같은 화면이 뜨실겁니다 'ㅅ '! 정상적인 설치가 된거죠..

▲ SVN 등록을 한번 해봅시다..

   Repositories 의 우클릭하여 Create New Repository 를 선택합니다.

▲ 바로 다음을 클릭합니다.

▲ SVN 프로젝트명을 입력하신후 다음으로 갑니다.

▲ 역시 다른거 손댈필요없이 다음!!

▲ 마찬가지로 다음을 클릭해줍니다.

▲ Repository URL 이 SVN 경로입니다.

   MASTER 이라는 부분은 해당 서버의 IP를 넣어주시면 접속이 가능하기 때문에

   이클립스에서 해당 주소로 SVN 을 등록해주시면 됩니다.

▲ 추가된 web2..

   이클립스와 연동하신후 커밋을 해주시면 이쪽에 구성이 쭉 되어 올라가게 될겁니다..

   개발하시는데 SVN 정도는 알아주셔야 파일관리 하시기 편하실겁니다 ' ㅇ'!!

그외 여러가지 기능들이 있으나, 찾아보시면 쉽게 아실겁니다.

도움 많이 되시길 바랍니다.

오래전 버전으로 되돌리기 할대는 먼저 소스를 최신버전으로 revert 한다음 되돌리고자 하는 버전으로 revert to this revision 한다

만일 특정리비전으로 되돌렸는데 병합등의 문제로 컴파일 에러가 나면  소스를 revert 한 다음 최신소스로 업데이트 받아본다

만약 현재 작업하고 있는 local 이 최신 파일이고 이 파일로 commit 해야 한다면

현재 local 을 빽업해놓고 원본을 update 받음 다음 빽업의 svn 파일을 지우고 업데이트 받은 파일에 빽업한것을 덮어씌우면 됨

http://blog.naver.com/sharpyoo?Redirect=Log&logNo=10102016073

http://andromedarabbit.net/wp/ankhsvn/

http://blog.naver.com/saram95/90093439339

anksvn 과 winmerge Diff를 사용하고싶을때

"C:\Program Files (x86)\WinMerge\WinMergeU.exe" -e -x -ub -dl "%bname" -dr "%yname" "%base" "%mine"

VS - 도구 - 옵션 - Source Control - 플러그인 선택 AnkhSVN 으로 설정

VS - 도구 - 옵션 - Source Control - Subversion

문제점

안타깝게도 Visual Assist X과 AnknSvn이 충돌을 일으키는 기능이 하나 있다. 바로 커밋! 커밋할 때 Visual Assist X이 커밋 로그 창에 함수 목록을 보여 주려 하고 이 때문에 글자가 안 써 진다. Visual Assist를 끄던가, 메모장에 로그를 써서 커밋 로그 창에 붙여넣어야 한다.

svn 에서 이름 변경후

복사된 사본을 체크아웃하여 로컬 디렉토리에 복사되도록 한다음 원본 삭제

http://kblog.popekim.com/

2013년 1월 10일 목요일

Version Control System에서 공통적으로 사용하는 용어들

저의 잘못된 번역으로 인한 오해와 잘못된 지식의 전달을 우려해서 원문과 함께 번역문을 기술합니다.

! NOTICE ! This article is excerpted from http://en.wikipedia.org/wiki/Revision_control

Baseline (베이스 라인)

    An approved revision of a document or source file from which subsequent changes can be made.

    계속 변경된 문서 또는 소스파일의 승인된 리비전

Branch (가지,분기,브랜치)

    A set of files under version control may be branched or forked at a point in time so that, from that time forward,

    two copies of those files may be developed at different speeds or in different ways independently of the other.

    시간상 어떤 시점에서 버전 관리하의 한 셋트의 파일들은 분기될 수 있다. 그래서 그 분기 시점 이후 이러한 파일들의 두 복사본들은

    서로 독립적으로 다른 속도로 또는 다른 방법으로 개발될 수 있다.

    A check-out (or checkout or co) creates a local working copy from the repository. Either a specific revision is specified,

    or the latest is obtained.

    체크 아웃은 저장소로 부터 로컬 작업본을 생성한다. 특정 리비전이 명시되거나 최근 리비전이 획득된다.

    A commit (check-in, ci or, more rarely, install or submit) occurs when a copy of the changes made to the working copy

    is written or merged into the repository.

    작업본에 변경이 있거나 저장소로 병합되었을 때 커밋이 일어난다(발생한다).

    A conflict occurs when two changes are made by different parties to the same document,

    and the system is unable to reconcile the changes. A user must resolve the conflict by combining the changes,

    or by selecting one change in favour of the other.

    충돌은 동일한 문서에 다른 부서에 의해 두개의 변경있을 때 그리고 시스템이 변경사항들을 조정, 일치시킬수 없을 때 발생한다.

    사용자는 변경사항들을 결합하거나 하나의 변경을 선택함으로써 충돌을 해결해야만 한다.

    A change (or diff, or delta) represents a specific modification to a document under version control.

    The granularity of the modification considered a change varies between version control systems.

    변경은 버전 관리하에 문서상에 특정 수정을 말한다.

    On many version control systems with atomic multi-change commits, a changelist, change set, or patch identifies the set of

    changes made in a single commit. This can also represent a sequential view of the source code, allowing source to be examined

    as of any particular changelist ID.

    극소 다중 변경 커밋을 지원하는(?) 많은 버전 관리 시스템에서, 변경 리스트, 변경 셋, 패치는 단일 커밋에 있어서의 변경사항들의

    한 셋트이다. 이는 소스코드의 순차적인 관점을 나타내며, 어느 특정한 변경 리스트 ID로서 소스가 검사되도록 한다.

    A stream (a data structure that implements a configuration of the elements in a particular repository) whose configuration

    changes over time, with new versions promoted from child workspaces and/or from other dynamic streams. It also inherits

    versions from its parent stream.

    스트림(특정 저장소에서 요소들의 구성을 수행하는 데이타 구조)의 구성은 자식 워크스페이스 또는 다른 동적 스트림에 의해 

    시간에 따라 변경된다. 이는 부모 스트림으로 부터 버전을 상속한다(물려받는다).

    An export is similar to a check-out except that it creates a clean directory tree without the version control metadata used in a

    working copy. Often used prior to publishing the contents.

    엑스포트는 작업본에서 사용되는 버전 관리 메타데이타 없이 순수한 디렉토리 트리를 생성한다.

    종종 항목들을 공표하기에 앞서 사용된다.

    The most recent commit. 가장 최근의 커밋

    An import is the action of copying a local directory tree (that is not currently a working copy)

    into the repository for the first time.

    임포트는 처음에 (현재의 작업본이 아닌) 로컬 디렉토리 트리를 저장소로 복사하는 작업이다.

Mainline (메인 라인) 

    Similar to Trunk, but there can be a Mainline for each branch.

    Trunk와 유사하지만 각 브랜치에 대한 메인라인이 있다.

    A merge or integration brings together two sets of changes to a file or set of files into a unified revision of that file or files.

    병합 또는 통합은 파일 또는 파일 세트상의 두 변경 세트를 파일 또는 파일들의 단일 리비전으로 만든다.

• This may happen when one user, working on those files, updates their working copy with changes made, and checked into the repository, by other users. Conversely, this same process may happen in the repository when a user tries to check-in their changes.
• It may happen after a set of files has been branched, then a problem that existed before the branching is fixed in one branch and this fix needs merging into the other.
• It may happen after files have been branched, developed independently for a while and then are required to be merged back into a single unified trunk.

Repository (저장소)

    The repository is where the current and historical file data is stored, often on a server.

    저장소는 현재 그리고 옛 파일 데이타가 서버상에 저장되는 곳이다.

 

Reverse integration (역 통합)

    The process of merging different team branches into the main trunk of the versioning system.

    다른 팀 분기를 버전 시스템의 주요 본체(trunk)로 병합하는 프로세스이다.

 

Revision (리비전, 버전)

    A revision or version is one version in a chain of changes.

    리비전 또는 버전은 일련의 변경사항들에 있어서 한 버전이다. 

 

Tag (태그)

    A tag or release refers to an important snapshot in time, consistent across many files.

    These files at that point may all be tagged with a user-friendly, meaningful name or revision number.

    태그 또는 릴리즈는 일관된 많은 파일들과 시간상의 중요한 스냅샷을 참조로 한다.

    이 시점에서의 파일들은 친숙한, 의미있는 이름 또는 리비전 넘버로 태그될 수 있다.

 

Trunk (트렁크, 본체)

    The unique line of development that is not a branch (sometimes also called Baseline or Mainline)

    분기가 아닌 개발의 유일한 라인이다. (때때로 베이스 라인 또는 메인 라인으로 불려진다.)

 

Resolve (해결)

    The act of user intervention to address a conflict between different changes to the same document.

    동일 문서상에 다른 변경사항들 사이의 충돌을 설명하기 위한 사용자 중재 활동이다.

 

Update (갱신)

    An update (or sync) merges changes that have been made in the repository (e.g. by other people) 

    into the local working copy.

    갱신은 (다른 사람에 의해) 저장소에서의 변경 사항을 로컬 작업본에 병합한다.

 

Working copy                                                                              

    The working copy is the local copy of files from a repository, at a specific time or revision. All work done to the files in a

    repository is initially done on a working copy, hence the name.

    작업본은 저장소로 부터 특정 시간 또는 리비전의 파일 로컬 복사이다.

    저장소에서 파일들에 모든 작업의 완료는 초기에 작업본에 완료된다.

[출처] Version Control System에서 알아두어야 할 용어|작성자 지연아빠

http://cafe.naver.com/vslinlin/50

먼저 [3탄] TortoiseSVN을 이용한 업데이트 글에 다시 빌드하라는 내용은 빠졌는데
혹시나 하고 모르실 수도 있기에 언급해드립니다.
업데이트 하신 후 소스 수정하시고 빌드하지 않으면 업데이트 하나마나입니다.^^
까먹지 마시길...



이번에 다뤄질 내용은 TortoiseSVN 응용입니다.

검색을 활용하면 얼마든지 사용법은 나옵니다.
그래서 여기서는 소스구축 후 패치파일 제작과 적용만 소개하고자합니다.

업데이트 할 때마다 매번 config 폴더의 파일을 수정해야합니다.
물론 처음 시작할 땐 일부로라도 그렇게 진행하시는 게 좋습니다.
구축 후 설정법을 익히는 데 도움이 될 수도 있습니다.

이제 매번 똑같은 설정 바꾸기 귀찮아지게 되면 한번쯤 "쉽게 하는 방법 없을까"라는
고민은 대부분 구축해본 분들이라면 해보셨을꺼라 생각합니다.
물론, 여러가지 방법이 있지만 여기서는 TortoiseSVN으로 패치파일을 만들고
다시 적용하는 법을 소개하겠습니다.

1. 주요 변경파일 패치파일 제작

우선 아래의 폴더로 이동해서 각각의 파일들을 본인 서버 구성에 맞게 수정합니다.
수정할 때는 EditPlus 등의 프로그램을 이용하시면 편리합니다.

수정을 다 마치고 저장하면 아래 그림처럼 아이콘에 느낌표 표시가 생깁니다.
이 느낌표의 의미는 내용이 원본 소스와 다르게 수정이 되었다는 의미지
파일에 문제가 있다는 표시가 절대 아닙니다.


해당 아이콘의 설명은 TortoiseSVN 설정에 보면 나와있으니 참고하세요.


아래와 같은 방법으로 패치파일을 만들겠습니다.
소스 최상위 폴더 오른쪽 마우스 클릭 -> -> TortoiseSVN -> 패치 생성


수정된 내역이 뜨고 체크가 된 파일들에 대한 패치 파일을 만들겠다는 내용입니다.


"저장 위치"를 선택하고 "파일 이름"을 쓴 다음 "저장" 버튼을 눌러주세요.


아래 그림처럼 패치파일의 내용을 보여 주면서 지정한 위치에 파일이 저장됩니다.


이로써 다음에 업데이트 후 한방에 변경하기 위한 패치파일 제작은 끝났습니다.


2. 리비전 업데이트하기 전 되돌리기

일단, 소스에 인위적인 수정이 들어갔으므로
업데이트 하기 전에 원본 소스로 되돌리는 작업을 진행합니다.
이유는 업데이트시 충돌이 발생할 수도 있기 때문입니다.
방법은 매우 간단합니다.
노보팩 기준으로 \SVN AIONEmu Source\aion-emu 오른쪽 마우스 클릭해서
아래 그림처럼 되돌리기를 실행해줍니다.
여기서 되돌리기란 원본 리비전으로 복원한다는 의미입니다.


모두 선택하고 확인을 누릅니다.


모두 진행된 후 확인을 눌러주면 원본 리비전으로 복원됩니다.



3. 리비전 업데이트

리비전 업데이트 합니다. 방법은  [3탄] TortoiseSVN을 이용한 업데이트 글에 나와있습니다.


4. 패치하기

빌드를 진행하기 전에 먼저 만들었던 패치파일을 이용해서 패치를 진행합니다.
패치파일에서 오른쪽 마우스 클릭해서 하는 방법과
소스폴더에서 오른쪽 마우스 클릭해서 하는 방법이 있습니다.

여기서는 패치파일에서 패치적용을 진행해보도록 하겠습니다.
아래와 같이 만들어진 패치파일을 오른쪽 마우스클릭 -> TortoiseSVN -> 패치 적용 클릭합니다.


위에서 패치 새성할때 소스의 최상위 폴더를 선택했듯이 패치 적용시에도 동일하게 선택합니다.


아래와 같은 창이 뜨면서 패치될 파일들을 보여주게 되는데그 창에서
오른쪽 마우스 클릭 -> Patch all을 실행합니다.
각각의 파일을 더블클릭하면 어떻게 수정이 되는지 TortoiseMerge를 통해서 확인할 수도 있습니다.


아래 그림처럼 패치가 완료되면 파일리스트 색상이 회색으로 바뀌면서
마지막 파일의 패치전과 패치후가 TortoiseMerge에 보여지게됩니다.


이로써 매번 수정해야하는 주요 설정 파일을
미리 만들어둔 패치파일을 통해 간단히 변경할 수 있습니다.

간혹 패치될 원본소스가 이전과 다르게 업데이트 되어 수정되는 경우도 있습니다.
그럴땐 패치될 파일을 보여줄때 빨간색으로 간혹 나오기도합니다.
TortoiseMerge라는 프로그램이 충돌한 파일을 해결하는 역할도 하긴 하는데
되도록이면 이럴 경우엔 강제로 진행하기보다는
일단은 빨간색으로 나온 파일을 더블클릭해서


정상적으로 바뀌는 지 확인 한 후 패치를 진행하도록 합니다.
아래 내용의 뜻은
- 라고 표시되는 줄을 삭제하고
+ 라고 표시되는 줄을 넣겠다는 의미입니다.


다른 사람이 올린 패치파일을 적용하다보면 위와 같은 상황이 많이 생깁니다.
제가 마지막으로 올린 패치파일(유닉2021_kit_end.patch)도 현재 최신리비전에 적용시 충돌이 발생하며
정상적으로 병합도 되지 않는 문제가 발생합니다.
이를 개인적으로 충돌이 나지 않게 해결하는 방법은 분명히 있습니다.
원본과 패치되는 부분을 자세히 비교해서 수동으로 수정해 주는 것이 가장 현명하다고 판단됩니다.

이제 빌드하고 서버 구동하면 됩니다.
수고하셨습니다.

Global ignore Pattern : 부분에

아래와 같이 쓴다

*.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo *.rej *~ #*# .#* .*.swp .DS_Store *.Debug Debug *.Release Release ipch *.sdf *.ipch *.exe *.ncb *.opt *.plg *.vsp *.lib LIBD LIB dump *.dmp errorReport log

http://www.phpk.org/archives/181

프로그램을 개발하면서 SVN 서버가 필요한 경우가 있습니다. VisualSVN Server는 Windows 기반에서 간편하게 SVN 서버를 구성해 줍니다.

웹 사이트에서 VisualSVN Server를 내려 받으신 후 msi 파일을 실행하면 설치를 시작합니다.

화면 1 VisualSVN Server 설치 시작 화면

VisualSVN Server는 Apache 웹 서버와 Subversion을 포함하고 있습니다. 이미 설치하려는 시스템이 Apache가 설치되어 있어도 Apache가 사용하는 포트가 중복되지만 않는다면 문제 없이 사용할 수 있습니다.

화면 2 서버 설정 화면

VusialSVN Server를 설치할 위치와 소스 코드를 저장할 저장소(Repositories) 위치를 지정할 수 있습니다. 기본 서버 포트는 8443이며 SSL을 통해 접속하게 되어 있습니다. SSL을 사용할 필요 없으시다면 Use secure connection에 V 표시를 없애면 됩니다.

인증 (Authencation)에서는 VisualSVN Server에서 사용자 그룹과 사용자를 관리할 것인지 Windows 에 이미 지정된 사용자 그룹과 사용자 정보를 사용할 것인지를 선택합니다.

Subversion authentication과 Windows authentication 차이

인증 방법의 차이는 아래 화면처럼 Subversion authentication을 선택하면 VisualSVN Server에서 사용자 그룹을 생성하고 사용자를 관리할 수 있습니다. 반면 Windows authentication 을 선택하면 Windows 에 등록된 사용자 이름과 비밀번호로 접근할 수 있습니다.(제어판 -> 사용자 계정)

여러 사람과 같이 사용해야 하는 경우라면 Subversion authentication을 사용하는 것이 보다 안전할 것으로 생각됩니다.

화면 3 Subversion authentication 사용 화면

설치 후 가장 먼저 사용자를 추가합니다. 원하는 사용자 이름과 비밀번호를 입력하여 사용자를 추가합니다.

화면 4 사용자 추가 화면

그리고 사용자 그룹을 만듭니다. 원하는 사용자 그룹 이름을 입력합니다. 사용자 그룹 추가 화면 아래 Add 버튼을 클릭해서 사용자 그룹에 포함할 사용자를 선택합니다.

화면 5 사용자 그룹 추가 화면

화면 6 사용자 그룹에 사용자를 추가하는 화면

이제 왼쪽 트리 화면에서 VisualSVN Server를 선택하여 시작 화면으로 돌아오면 오른쪽 화면의 Status 항목에 SVN Server URL을 클릭하여 저장소에 접근할 수 있습니다.

Internet Explorer로 URL에 접속하면 보안 인증서에 문제가 있다는 경고 화면을 보게 됩니다. 이 경고는 SSL 인증서가 사설 인증서라는 것을 알려주는 것인데 VisualSVN Server에서 https 사용으로 선택했기에 나타나는 화면이므로 “이 웹 사이트를 계속 탐색합니다(권장하지 않음).”을 선택하면 됩니다.

화면 7 보안 인증서 문제 안내 화면

사용자 이름과 비밀번호를 입력하면 VisualSVN Server의 SVN 저장소를 볼 수 있습니다.

화면 8 VisualSVN Server의 SVN 저장소 화면

저장소 생성

SVN 저장소는 시작 화면에서 “Create new repository…” 를 선택하거나 마우스 오른쪽 버튼을 눌러 문맥 메뉴를 통해 생성할 수 있습니다.

화면 9 저장소 생성 문맥 메뉴

저장소 생성 창이 뜨면 저장소 이름을 입력합니다. 개발팀에서 사용할 저장소라면 화면과 같이 DevTeam 이라고 짓는 것도 좋은 예입니다.

화면 10 저장소를 생성하는 화면

저장소가 생성되면 화면 왼쪽에 DevTeam 이 추가됩니다. 이제 화면 오른쪽 상단에 있는 URL을 SVN 클라이언트를 이용해 접속하면 소스 코드를 관리할 수 있습니다.

화면 11 저장소가 생성된 화면

VisualSVN 웹사이트 : http://www.visualsvn.com/

지난번 svn 설치방법에 대해 포스팅 한 후 드디어 svn 연동을 해 보았다!!!!

이번 소프트웨어실습3 프로젝트를 위해서 서버를 임대를 하여 svn을 설치하고 기타 등등을 설치해서 활용을 하려 했으나 금전적 이유로 인해 고민중에 병희형에게 구글code에 대해 듣게 되었다.

구글 code에서 새로운 프로젝트를 생성하며 원하는 소스 관리 툴을 선택하게끔 되어 있으며 난 svn을 선택하였다.

자! 이제 연동을 해보자!

지금부터 진행 될 내용은 일단 svn이 뭐하는 것인지 알고 있으며, 해당 url과 계정을 가지고 있으며, visual studio에 이전에 포스팅한 svn 설치 방법대로 설치했다는 가정 하에 진행하겠다!

Step1. 해당 Subversion 메뉴 접근

Step2. 해당 Subversion Url 입력

위 그림의 작은 박스 안의 아이콘을 클릭하면 Url을 입력할 수 있는 화면이 활성화 된다. 우리가 알고 있는 Svn 레파지터리 Url을 입력 후 Ok 버튼 클릭

Step3. 해당 Svn 레파지터리 내에서 프로젝트 선택

해당 Svn Url이 유효하다면 위와 같이 하위 폴더들이 노출 된다.

우리가 원하는 프로잭트 파일을 선택하여 Open 버튼을 클릭 해준다. 

필자는 이미 Svn 계정 정보를 입력하였으며 저장하기를 하였기 때문에 노출이 안되었다.

계정이 없을 경우 Svn 관리자에게 생성 요청을 하자!

Step4. 해당 프로잭트를 Check out 받을 위치 선택

본인이 원하는 Local Directory를 선택 하고 OK 버튼 클릭

Step5. 해당 프로잭트를 Check out 중!!!!!! 두둥!

Step6. 간단한 Svn 연동한 프로젝트 파일 구성

 빨강 박스로 된 파일(Program.cs)과 파란채크표시가 된 프로젝트 등이 보일것이다.

빨강 박스로 된 파일, 폴더, 프로잭트는 Commit할 대상

파란 채크 표시가 된 파일, 폴더, 프로잭트는 최종적으로 자신이 checkout이나 update받은 대상

간단한 SVN용어 설명

Commit - 우리 로컬에 있는 파일 등을 Svn에 반영하는 작업

Update - 우리 로컬에 있는 파일에 Svn의 최신버전으로 변경하는 작업 ( 만약 수정중파일(빨강박스)의 경우 충돌이 발생할수 있음, 이건 적절한 경험을 해봄으로 습득 가능)

Checkout - 우리 로컬에 최초로 Svn 레파지터리에 있는 것을 다운 받는 작업

Step7. 간단한 바로가기 메뉴 설명

필요한 메뉴 항목에 대해서만 설명

Commit - svn서버로 반영

Show Changes - 현재 파일과 svn서버에 있는 파일과 비교

View History - 해당 파일이나 선택한 폴더 등의 이력을 노출

Revert - 현재 파일의 버전으로 원복(최신이 아닌 것을 유념)

 View History

 

 Show Changes

 

Revert

 

 

Commit - Log Message를 남겨주는 것은 필수!

자 이상으로 SVN 연동 및 테스트는 끝이 났다!

AnkhSvn-2.3.10838.vol1.egg 

AnkhSvn-2.3.10838.vol2.egg 

AnkhSvn-2.3.10838.vol3.egg

SVN을 사용해 왔기에

Visual studio 2010에서도 svn을 사용하기 위하여 설정 해 보았다.

http://ankhsvn.open.collab.net/downloads

무슨 정보등을 입력해야 한다... ㅎㅎ

파일첨부를 하였으니 다운받아 압축 풀고 긍정적인 방향으로 설치 하길 바라다.

visual studio가 켜져 있었다면 프로그램 재시작~

1. 도구 > 옵션 으로 들어간다.

2. 아래와 같은 화면의 메뉴에서 플러그인 변경

3. 변경 후 아래와 같이 svn 사용이 가능해진다. 

4. 연동은 추후 해본 후 블러깅 하겠당~

 AnkhSVN

http://ankhsvn.open.collab.net/

출처 : http://yonomi.net/?p=87

Visual Studio 2010에서도 Subversion을 이용해서 형상관리를 할 수 있게 되었나보다.

   

http://www.heartcomplex.net

Tortoise SVN

Tortoise SVN은 윈도우Windows 플랫폼 기반 SVN 클라이언트Client 프로그램이다. 윈도우 환경에서 설치하여 GUIGraphic User Interface 환경에서 이용할 수 있기 때문에 SVN의 복잡한 명령줄Command line 체계를 이용하지 않고도 손쉽게 사용이 가능하다.

다운로드 및 설치

Tortoise SVN은 공식 홈페이지(http://tortoisesvn.tigris.net/) 에서 다운로드 받을 수 있다. 자신의 윈도우의 운영체계 종류(32Bit / 64Bit)에 맞는 버전을 선택하여 설치 파일을 다운로드 받는다.

Tortoise SVN 공식 홈페이지

해당 홈페이지에서는 각 언어별 언어팩을 제공하고 있으며, 한글 역시 지원하고 있다-영어로 된 메뉴에 울렁증이 생긴다면 한국어 지원 팩을 다운로드를 받는다. 설치 파일 및 언어 팩의 인스톨 파일을 실행시켜 설치를 하면 Tortoise SVN이 실행 된다.

Tortoise SVN 사용에 꼭 필요한 기능들

SVN에 대한 기본 개념 및 Tortoise SVN에 대한 설명은 여기까지 하도록 하고, 본격적으로 Tortoise SVN을 업무에 활용하기 위한 기능 설명을 하도록 한다.

체크 아웃Check Out

체크 아웃은 저장소에서 자신의 컴퓨터로 작업 복사본을 가져오는 명령이다. 해당 명령을 수행하게 될 경우, 사용자 인증을 거친 다음, 저장소로 부터 파일들을 지정된 폴더로 복사 해 오게 된다.

• 작업 복사본을 저장 할 폴더로 이동한 후, 해당 폴더 윈도우에서 마우스 우클릭 한다. 메뉴 중 SVN Check Out을 선택한다.
  
  
  
• SVN Check Out을 선택했을 경우 아래와 같은 팝 업 윈도우가 나타난다.
  
  
  
  - URL of repository: 접속 할 저장소의 주소를 입력한다. 저장소의 주소는 SVN 관리자에게 확인한다.
  - Checkout directory: 자신이 작업 복사본을 저장 할 폴더의 위치를 입력한다(보통은 자동으로 입력되므로, 해당 위치가 맞는지 정도만 확인 하면 된다).
  - Checkout Depth: 어느 위치까지 체크아웃 할 것인지를 결정하는 옵션이다. 디폴트인 Fully recursive를 선택한다.
  - Revision: 복사할 작업 복사본의 리비전을 선택한다. HEAD revision을 선택 할 경우 가장 최신의 리비전을 받게 되며, 원하는 리비전의 번호를 입력하면 해당 리비전을 받을 수 있다.
  
  
• 모든 사항을 확인 한 후, OK 버튼을 누르면 다음과 같은 사용자 인증 팝 업이 나타난다.
  
  
  
  - Username: 자신이 발급 받은 사용자 이름을 입력한다
  - Password: 지정한 패스워드를 입력한다.
  - Save authentication: 이 항목에 체크 하게 될 경우 해당 컴퓨터에 인증 기록이 남아 다음 작업 부터는 인증 과정이 자동으로 이루어진다-저장 내역을 삭제하기 위해서는 TortoiseSVN의 환경 설정 옵션을 이용한다.
  
  
• 인증 절차를 마치면 체크 아웃 내역이 아래와 같이 실시간으로 표시 된다.
  
  
  
• 체크 아웃이 완료 되면 OK 버튼을 눌러 해당 팝 업을 닫는다.

커밋Commit

작업 복사본에서 자신이 해야 할 업무를 마무리 하였을 경우, 해당 작업물을 커밋하여 저장소로 내용을 전송해야 한다.

• 작업 복사본에서 폴더나 수정한 파일을 선택하여 마우스 우클릭을 하여 나타나는 메뉴에서 SVN Commit 을 선택한다.
  
  
  
• SVN Commit 선택 시 다음과 같은 팝 업 윈도우가 나타난다.
  
  
  
  - Message: 커밋에 들어가는 로그를 기록한다. 로그에는 이번 커밋에서의 변동사항, 팀원들이 확인해야 될 내용, 검색 태그 등을 간략하게 정리하여 입력하도록 한다.
  - Changes made: 커밋에 적용되는 파일의 목록과 적용 상태를 확인 할 수 있다. 아래의 체크 박스 옵션들을 통하여 리스팅을 조정하거나, 전체 선택/선택 취소를 할 수 있다.
  
  
• 로그 메시지 및 커밋 할 파일을 선택 한 후 OK 버튼을 누르면 아래와 같이 커밋 내역이 실시간으로 표시 된다.
  
  
  
• 커밋이 완료 되면 OK 버튼을 클릭하여 팝 업을 닫는다.

업데이트Update

자신이 작업을 진행하고 있는 작업 복사본을 저장소에 있는 최신 작업물로 교체하기 위해서 업데이트 명령을 이용한다. 이 명령을 이용하여 자신이 작업하고 있는 동안 다른 사람들에 의해 갱신 된 작업물들을 최신 파일로 내려 받아 변경 할 수 있다.

• 작업 복사본에서 업데이트를 실시할 폴더나 파일을 선택하여 마우스 우클릭으로 메뉴를 호출한다. 메뉴 중 SVN Update를 선택한다.
  
  
  
• 팝 업과 함께 업데이트 내역이 실시간으로 보여진다.
• 업데이트가 완료 되면 팝 업 하단에 Show log... 버튼과 OK 버튼이 활성화 된다.
  
  
  
  - Show log... 버튼을 클릭하면, 로그 팝 업이 열린다. 로그 팝 업 에서 각 리비전 별 로그 메시지를 확인 할 수 있다.
  - OK 버튼을 클릭하면 팝 업 이 닫힌다.

되돌리기Revert

작업을 하다보면, 자신의 현재 작업물을 버리고 이전 작업물로 되돌려야 할 경우가 종종 발생한다. 되돌리기 명령을 이용하면 최신 리비전으로 파일을 복구 시킬 수 있다.

• 작업 복사본에서 수정 한 파일 중 되돌리기를 수행해야 할 폴더나 파일을 선택하여 마우스 우클릭으로 메뉴를 불러낸 후, Tortoise SVN을 선택하여 서브 메뉴를 불러온다.
  
  
  
• 서브 메뉴 항목 중 Revert 를 선택하면, 아래와 같은 팝 업이 출현한다.
  
  
  
• 되돌리기를 실행 할 파일을 선택 한 후 OK 버튼을 클릭 하면 해당 파일을 저장소의 가장 최신 리비전으로 되돌린다.

잠금 및 잠금 해제Lock/Unlock

잠금 중심 버전 관리 방식을 채택하는 것이 아니라 하더라도, 자신이 작업하고 있는 작업물을 다른 팀원이 함부로 수정하지 못하게 막아야 할 필요가 발생 경우가 있다. 이때는 해당 파일이나 폴더 전체를 잠금 상태로 만들고 난 다음, 작업이 완료 된 이후 해당 파일의 잠금을 해제하면 된다.

• 잠금을 위한 파일 혹은 폴더를 선택하고 마우스 우클릭으로 메뉴를 불러낸 후, Tortoise SVN을 선택하여 서브 메뉴를 불러온다.
  
  
  
• 서브 메뉴 항목 중 Get Lock을 선택하면 아래와 같은 팝 업이 출현한다.
  
  
  
  - 해당 파일에 잠금을 거는 이유를 Enter a message describing why you ar locking the file(s). 항목에 서술한다.
  - 파일 리스트를 확인 한 후 OK 버튼을 클릭하면 해당 파일을 잠금 상태로 만든다.
• 저장소에 해당 파일의 잠금 상태가 전송 되면서 잠금 처리가 완료 된다.
  
  
  
• 잠금 상태를 다시 잠금 해제 상태로 변환하기 위해서는 마우스 우클릭으로 메뉴를 불러낸 후, Tortoise SVN의 서브메뉴를 불러온다.
  
  
  
• 서브 메뉴 항목 중 Release Lock을 선택하면 아래와 같은 팝 업이 나타난다.
  
  
  
  - Unlock을 할 파일 목록을 확인 한 후 OK 버튼을 클릭하면 해당 파일을 잠금 해제 상태로 만든다.