별거 아닌 내용이지만, 내 경우는 SVN 에 익숙하지 않다보니(사실 매뉴얼을 제대로 안읽어서 그렇다. -_-;) 몇일 동안 삽질했다. 학교 연구실과 집을 드나들며, 자꾸 SVN 에 실패하고 대신 일일이 구글의 이메일로 자료를 보냈다.

SVN 은 나름대로 단순하지 않은 구조를 가진다. 매뉴얼이나 다름 없는 책만 해도 300페이지가 넘도록 있으며[1] 단순히 파일을 주고 받는 것에 그치지 않고 효과적으로 여러사람들이 코드를 공유할 수 있도록 특이한 방법을 사용한다. 자세한 설명이나 서버 세팅하는 법은 생략하고(사실 잘 모른다.) 그냥 내가 올리려는 파일들을 기준으로 클라이언트에서 어떻게 사용할 수 있는지에 대한 간단한 소개만 하려고 한다. 단, 여기서 설명하는 것은 윈도우 기준이고, 다른 곳에서는 방법은 많이 다르다. 하지만 용어는 같다!

일단 내가 SVN 서버에 올리려 하는 것은 다음의 폴더들이다.

TestProgram, FourierTest, SimpleFluidSimulator

올리려고 하는 주소는 https://hybrid.googlecode.com/svn/trunk/ 이다.
사실 위의 주소는 내가 사용하는 주소가 아니다. 원래 주소를 감추기 위해 hybrid 를 넣었다.[2]

1. 일단, 윈도우즈에서 편리하게 사용하기 위해 TortoiseSVN 을 설치한다. 이것은 Windows Explorer 에서 편리하게 사용할 수 있는 프로그램이다.


2. 이 프로그램을 설치 후 바탕화면이나 Explorer 에서 오른쪽 버튼을 누르면 TortoiseSVN 이 생기는 것을 볼 수 있다. 거기서 Repo-browser 를 누른다.

이것은 Repository Browser로 Repository 를 볼 수 있다. 현재는 비어 있는 상태다. 여기에 오른쪽 버튼을 눌러 'Add' 로 추가를 하거나 직접 Explorer 로 부터 드래그를 해서 추가를 할 수 있다.

3. 이상한 점이, 이렇게 넣으면 Repository 에는 제대로 들어가지만, 내 컴퓨터에서는 제대로 SVN 을 인식을 못한다. 일단은 이것을 백업하던지 해서 다른 곳으로 옮겨둔다. 올려보낸 자료를 다시 다운 받을 것이다. 이를 위해서 중복이 되지 않도록 지우거나 백업을 해야 한다는 말이다.[3]

그 다음에 Checkout 을 한다. Checkout 은 서버에 있는 것을 내 컴퓨터로 다운 받는 것을 의미한다. 단, 같은 파일이 존재하면 안된다. 파일 이름이 겹치면 안된다. 그래서 위에서 백업을 한것이다. HEAD revision 과 Revision 의 차이는 매뉴얼을 참고한다. 일단은 HEAD revision 만 사용하면 된다.

Checkout 을 하면 이런식으로 다운을 받게 된다. At revision 88 은, 현재 88번째 revision(수정)이라는 뜻이다. 이중 HEAD 는 제일 최신을 뜻하는 것이고, 이러한 구조는 사실상 트리 구조를 이루고 있다.(자세한 설명은 매뉴얼을 참고.)

4. 그러면  이렇게 현재 내 컴퓨터에 체크 표시가 된 상태로 다운이 받아져있다.(이 디렉토리 안을 살펴보면 숨겨진 디렉토리로 .svn 이라는 디렉토리가 있다. Explorer 는 이것으로 SVN 에 관한 정보를 다룬다.

시험삼아 FourierTest 안에 있는 main.cpp 를 수정한 후 저장해봤다.

그러면 위와 같이 main.cpp 를 담고 있는 FourierTest 디렉토리에 체크표시대신 느낌표가 표시된다. 물론 이 안에 있는 main.cpp 파일도 느낌표로 보여지게 된다.

5. 이때 이 디렉토리나 실제 main.cpp 파일에서 오른쪽 버튼을 눌러서 할 수 있는 행동은 다음과 같다.

Commit : 내 컴퓨터에서 Repository 로 저장하는 것을 의미한다.
Update : 이것은 Repository 의 변경사항을 내 컴퓨터에 적용시키는 것을 의미한다. 지금은 내가 main.cpp 파일을 변경 했기 때문에, Update 를 해도 아무런 변화가 일어나지 않는다.(내가 아닌 다른 사람이 Repository 를 변경시켰을 때, Update 를 적용할 수 있다.)
Revert : Commit 전에 방금 내가 한 수정을 취소할때 사용된다. 즉, 아직 Commit 을 하지 않았다면, 현재 Repository 에는 내가 수정한 내용이 적용되지 않았을 것이다. 이때 Revert 하면, Repository 에 있는 수정전의 내용이 내 컴퓨터로 적용된다.
Update to revision # : 원하는 번호의 Revision 으로 되돌릴 수 있는 기능이다.(최신 Revision 은 HEAD 이다. 실수로 잘못 수정을 한 후 Commit 을 했더라도, 그 HEAD 이전의 Revision 으로 되돌릴 수 있다.)
Lock/Unlock : 이름만으로도 유추할 수 있듯이, Lock 을 걸면 다른 사람이 이것을 변경할 수 없다.(정확히 말하면 읽기는 가능하니까, 수정을 해도 Commit 이 안되는 것이다.) 이것은 Unlock 이 될 때까지 지속되는데, 이것이 일종의 문제이다. (사람의 실수로) Unlock 이 장시간 안되면 효율적인 작업에 문제가 생길 수 있다.(그렇기 때문에, Repository 는 revision 등의 기능과 함께 Tree 구조를 구성한다.)

6. 작업을 하다가 새로운 파일을 만들 수 있다.
그럴때는 그러한 파일이나 디렉토리에서 오른쪽 버튼을 눌러 Add 를 누른다 . 그렇게 업로드를 시키면 파일이나 디렉토리에는 위의 느낌표 마냥 + 표시가 나온다.(앞에서는 Add를 눌러도 +가 생기지 않아 다시 Checkout 을 해야만 했다. 그 차이는 아래에 다시 설명하겠다.)

(파일마다 +가 보이는 것을 확인할 수 있다. 이때, .svn 은 숨겨진 디렉토리이고, ETC와 Ankh.load 처럼 SVN 에 추가 된 파일과 추가되지 않은 파일이 같은 곳에 존재할 수 있다.)
이 +의 뜻은 Repository 에는 없다는 의미로, Commit 을 하면 Repository 에 새로 추가가 될 예정이라는 뜻이다. 일일이 모든 파일을 선택해 Commit 하거나, 간단하게 이전 디렉토리로 가서 디렉토리 통채로 Commit 을 할 수도 있다.(당연히 Commit 이 적용될 파일들만 알아서 적용된다.)

7. 이 정도면 기본적으로 SVN의 기능들은 잘 활용할 수 있다. 그중에 문제가 됐던 것 하나가 있었다.

처음에는 Explorer 에서는 Add를 할수도 없었고, Repository 에서 Add를 했는데도 귀찮게 다시 Checkout 을 해서 받아와야만 했다. 하지만 나중에는 알아서 + 표시가 되서 편하게 사용할 수 있었다. 이 차이는 현재 디렉토리에 .svn 의 유무에 따라 달라진다. 즉, .svn 가 있으면 현재 그 디렉토리는 서버의 Repository 와 연결이 되어 있으므로, Add를 하면 알아서 Repository 의 어느 주소로 들어갈지 안다는 말이다. 그렇기 때문에 + 표시가 되어 Commit 으로 간편하게 해결이 되는 것이다.

이것은 아마 내가 SVN 를 사용하는데 미숙함이 있지 않았나 생각이 드는데, 나로써는 별다른 방법이 없었다.

8. 두번째로 남길 팁은, Ankh 에서 제작한 Visual Studio .NET Addon 인  AnkhSVN[4] 이다. 이것을 사용하면, 위에서 사용한 Subvision 을 그대로 .NET 에서 같이 활용할 수 있다.(비슷하게 작동한다.) 단, 위의 TortoiseSVN 없이 이것만 사용하기에는 다소 불편한 점이 있었다. 그래서 위의 방법으로 SVN 을 잘 세팅 해놓은 후 AnkhSVN 을 활용하는 것을 추천한다. 이것을 추가하면, 다음과 같이 .NET 에도 SVN 의 상태를 확인할 수 있다.

위와 같이 친절하게 파일과 솔루션에 모두 표시가 된다. 물론 여기서도 Update 나 Commit 이 가능하고, Diff 를 통해 소스 비교까지 할 수 있다.(이 Diff 기능이 TortoiseSVN 에도 있는지는 잘 모르겠다.)

결론적으로... SVN 는 사실상 그렇게 간단한 형태는 아니었다. 그렇기 때문에 매뉴얼을 자세히 읽고 시작하는게 필수였지만, 300페이지나 되는 매뉴얼을 자세히 읽기는 쉬운 일이 아니다.(당장은 필요 없는 기능들도 많고..) 그렇기 때문에 일단 초보자 수준에서 따라하기 쉬운 내용을 적었다. 아무리 RTFM 이라지만, 처음에 헤메는 것을 조금 덜고자 길지만 캡쳐해가며 주욱 적어보았다. (역시 이런건 적고나면 더더욱 아무것도 아니다. -_-; 난 헤맸는데 ㅜ_ㅜ) 참고로 이 이외에도 더 많은 기능들이 있으니, 관심이 있는 사람은 CollabNet, Wikipedia - Subversion, Tigris.org 등을 참고한다.

google_protectAndRun("ads_core.google_render_ad", google_handleError, google_render_ad);

http://www.cyworld.com/hma1009/2677627

http://www.cyworld.com/hma1009/2677616

파이프(pipe)
-두 프로그램을 연결해주는 연결 통로의 의미("|" 문자를 사용함)
# ls -l /etc | more     - 출력된 내용이 한꺼번에 넘어갈경우, 한 페이지씩 나눠 보겠다는 의미.

필터(filter)
- 필요한 것만 걸러주는 명령어
 ( grep, tail, wc, sort, awk, sed 등, 주로 파이프와 같이 사용된다.)

# ps -ef | grep bash    - "bash"라는 글자가 들어간 프로세스만 출력
# rpm -qa | grep bind   - 설치된 패키지 중에서 "bind"라는 글자가 들어간 패키지를 출력

리다이렉션(redirection)
-표준 입출력의 방향을 바꿔줌
(표준 입력은 키보드, 표준 출력은 모니터이지만 이를 파일로 처리하고 싶을 때 사용)

#ls -l > aa.lst                    - ls -l " 의 결과를 화면에 출력하지 않고 aa.lst 라는 파일에 쓰도록한다
#ls -l >> aa.lst                  - aa.lst 파일이 존재하면 기존 내용에 이어쓴다는것을 제외하곤 위와 똑같음
#sort < aa.lst                     - aa.lst 파일을 정렬해서 화면에 출력
#sort < aa.lst  > bbl.st        - aa.lst 파일을 정렬해서 , bb.lst 파일에 쓴다.

C shell boune shell > 표준출력을 새로운 파일로 같음 >!-d 표준출력을 기존의 파일로 x >> 표준출력을 기존의 파일로 덧붙임 같음 < 표준입력을파일에서 같음 >& 표준출력,에러를 새로운파일에 x >&! 표준출력,에러를 기존의파일에 x >>& 표준출력,에러를 기존의파일에 덧붙임 x 1> x 표준출력을 파일로 2> x 표준에러를 파일로 >&2 x 표준출력,에러를 모두 파일로 2>&1      x                                                표준출력,에러를 모두 표시

*메모리 누수 잡기
-----------------------------------------------------------------------------------
#include <crtdbg.h> 를 추가한다.
코딩의 마지막 부분에
_CrtDumpMemoryLeaks(); 를 써준다.

F5를 눌러 컴파일을 하면 메모리 누수가 일어났을경우
메모리 누수가 일어난 번지(??)를 알려준다.

누수가 일어난 부분을 확인한 후
_CrtSetBreakAlloc(번지); 를 처음 부분에 써주고 F5를 눌러 컴파일 하면 그 부분을 찾아간다.
-----------------------------------------------------------------------------------

*NULL값을 확인하는 방법?
-----------------------------------------------------------------------------------
#include <assert.h>를 추가한다.
확인하고자 하는 변수(?)를 assert(변수); 이렇게 써준다 .
변수가 NULL값일경우 화면에 에러메시지를 표시해준다.
-----------------------------------------------------------------------------------




Visual Studio 에서 개발할 경우 메모리 누수를 확인할려면
디버그 모드에서 F5 (Ctrl+F5 아님) 로 프로그램을 실행하면 되는건 아시죠?
이때 C++ 의 경우는 new 를 사용하고 메모리 반환을 하지 않는경우 해당 위치를 output 창에 보여줍니다.
예를 들어 아래의 코드로 메모리 할당후 어디에서도 반환하지 않았다고 가정해봅시다.
           char *pszTest = new char[100] ;
F5 로 프로그램 실행후 종료하면 Debug 출력창에 아래와 같이 나옵니다.
Detected memory leaks!
Dumping objects ->
D:ProjectMemoryTest.cpp(60) : {73} normal block at 0x00374E58, 100 bytes long.
Data: <                > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.

F4 또는 위의 파일경로명을 더블클릭 하면 해당 위치 소스코드의 포커스를 이동해주기 때문에
메모리누수를 해결하는데 아주 편리합니다.
이렇게 가능한 이유는 비쥬얼스튜디오에서 프로젝트 생성시 자동으로 추가된 아래의 구문 때문입니다

#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
보시면 아시겠지만 new 라는 놈을 DEBUG_NEW 로 다시 정의하였습니다.
실제 디버그에선  new 를 사용해도, DEBUG_NEW 가 실행하게 되는것입니다.
그렇다면, 이 DEBUG_NEW 의 정체가 뭘까요?

DEBUG_NEW 가 정의되어있는 소스코드를 가보겠습니다.
DEBUG_NEW 는 <AFX.H> 에 정의되어 있고, 내용은 아래와 같습니다.
#define DEBUG_NEW new(THIS_FILE, __LINE__)
오호라~ new 가 연산자 오버로딩 되어 있는게 확인됩니다.
일반적으로 우리가 생각하는 new 는 인자로 할당할 크기만 주게 되어 있습니다.
하지만, 위의 구문을 보면 해당 위치의 파일명과 라인수를 지정하게 되어 있군요.
다시말해, new 를 사용할때마다 사용된 곳의 파일 경로와 해당 라인수를 메모리에 함께 등록하는 것입니다.

결국 해당 메모리가 제거되지 않았을땐, 메모리에 기록해둔 파일경로와 라인수를 참조해서 디버그 출력창에 뿌려주고
이를 식별자로 사용하여 이동하기 쉽게 해주고 있습니다.
여기까지는 비쥬얼 스튜디오가 자동으로 해주기 때문에 크게 신경쓸 일이 없었습니다.
하지만, 문제는 C 코드일 경우입니다.
비쥬얼스튜디오는 불행하게도 C 코드로 된 프로젝트를 생성하는 마법사가 없습니다.
그러다보니 자동으로 생성해주는 메모리 누수 매크로도 제공하질 않습니다.
실제 C 코드에서 사용하는 malloc 을 사용해서 메모리 해제 하지 않고 결과를 보겠습니다.
char *pszTest2 = (char*)malloc(100*sizeof(char)) ;
위코드를 수행후 종료하면 디버그출력창에 아래와 같이 나옵니다.
etected memory leaks!
Dumping objects ->
{73} normal block at 0x00374E58, 100 bytes long.
Data: <                > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
도대체 어떻게 하라는건지…
더블클릭해도 아무 반응도 없고, 어디서 메모리 해제가 일어났는지 아무런 정보도 주질 못하고 있습니다.

그렇다고 포기할순 없죠.
C++ 의 new에 사용했던 방식대로 C 의 malloc 에도 똑같이 해주면 될 것 같습니다.
malloc 할때 현재 파일경로와 라인수를 식별자로 함께 등록해주면 되겠군요.
그렇다면 이러한 매크로(DEBUG_NEW와 같은)를 직접 만들어야 할까요?

친절하게도 비쥬얼스튜디오 헤더파일에 미리 다 만들어 놨더군요.
우선 결과 코드를 보겠습니다.
#ifdef _DEBUG
#include <crtdbg.h>
#ifdef malloc
#undef malloc
#endif
#define malloc(s) (_malloc_dbg( s, _NORMAL_BLOCK, __FILE__, __LINE__ ))
#endif

new 를 사용할 때 처럼, malloc 을 다시 다른 함수를 사용하게 정의하였습니다.
위 코드를 C 소스코드의 상단에 위치시킵니다.
그런후 다시 아까의 코드를 수행후 종료하면 친절한 디버그 출력창으로 바뀐걸 볼 수 있습니다.
Detected memory leaks!
Dumping objects ->
D:ProjectMemoryTest.c (68) : {73} normal block at 0x00374E58, 100 bytes long.
Data: <                > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.

위 매크로를 보시면 _malloc_dgb 라는 매크로가 보입니다.
우린 그저 가져다 쓴것에 불과하군요.
<crtdbg.h> 를 열어보시면 메모리 관련 함수인  malloc, calloc, realloc, expand, free, msize 에 대한
디버그용 매크로가 정의되어 있는걸 보실 수 있습니다.
그렇다면 _malloc_dgb 에서 사용된 인자들의 의미가 과연 무얼까요?
s 는 실제 할당할 크기(사이즈) 입니다.
_NORMAL_BLOCK 는 시스템에서 메모리를 할당할 때 사용되는 블록의 기본 단위 크기 입니다.
__FILE__ 은 현재 코드의 전체 경로명입니다.
__LINE__ 은 현재 코드의 수행중인 라인수 입니다.
다시,  crtdbg.h 를 보시면 free 라는 놈도 디버그용이 있습니다.
이왕 하는거 위에서 정의된 모든 메모리 관련 함수에 대해서 디버그용으로 변경해 봅시다.
#ifdef _DEBUG
#include <crtdbg.h>
         #ifdef malloc
         #undef malloc
         #endif
         #define malloc(s) (_malloc_dbg(s, _NORMAL_BLOCK, __FILE__, __LINE__ ))
         #ifdef calloc
         #undef calloc
         #endif
         #define calloc(c, s) (_calloc_dbg(c, s, _NORMAL_BLOCK, __FILE__, __LINE__ ))
         #ifdef realloc
         #undef realloc
         #endif
         #define realloc(p, s) (_realloc_dbg(p, s, _NORMAL_BLOCK, __FILE__, __LINE__ ))
         #ifdef _expand
         #undef _expand
         #endif
         #define _expand(p, s) (_expand_dbg(p, s, _NORMAL_BLOCK, __FILE__, __LINE__  ))
         #ifdef free
         #undef free
         #endif
         #define free(p) (_free_dbg(p, _NORMAL_BLOCK))
         #ifdef _msize
         #undef _msize
         #endif
         #define _msize(p) (_msize_dbg(p, _NORMAL_BLOCK))
#endif

이제 메모리누수 안녕~~~


출처 : Devpia