구차니의 잡동사니 모음

올 웬일이래 오랫만에 새거네 ㅋㅋ

머징

분리된 개발라인을 유지하는데 사용되는 브랜치에서, 당신은 몇몇 단계에서 브랜치에서 일어난 것을 트렁크 안으로 혹은 반대로 머지를 원할 것이다 

당신이 이것을 사용하기 시작하기 전에 매우 복잡하게 되더라도 서브버전에서 브랜칭과 머징이 어떻게 작동하는지 이해하는 것은 중요하다. 어떻게 사용되는지에 대한 다양한 예제와 전체 설명이 있는 서브버전 책의 "브랜칭과 머징" 챕터를 읽는 것을 매우 강력히 권장한다.

다음 알아야할 내용은 머징은 워킹카피안에서 이뤄진다는 것이다. 브랜치 안으로 변경점을 머지 하고 싶다면, 브랜치를 위한 워킹 카피를 체크아웃 해야 하고, 워킹카피에서 TortoiseSVN -> Merge의 머지 위자드를 실행한다.

일반적으로 수정되지 않은 워킹카피로의 머지를 수행하는 것은 좋은 생각이다. 당신의 워킹카피에 다른 변경점이 있다면 그것들을 먼저 커밋해라. 머지가 당신이 예상한대로 작동하지 않는다거나 변경점을 되돌리고 싶어 한다면, Revert 명령을 통해 머지 이전을 포함한 모든 변경점을 파기하게 될 것이다.

아래에 기술 하듯, 근소하게 다른 방향으로 다뤄지는 머지의 3개의 일반적인 사용예가 있다.  머지 위자드의 첫 페이지에서는 당신이 사용할 방법을 고르도록 물어 볼 것이다.

리비전 범위 머지

  이 방법은 당신이 하나나 혹은 그 이상의 리비전들을 하나의 브랜치로 (혹은 트렁크) 만들고

  다른 브랜치들을 가로질러 변경점을 복사(port)하길 원할 때 사용된다.

  서브버전에게 이것을 어떻게 행하는지 물어 보면: " 브랜치 A의 리비전 1 [부터] 브랜치 A의 리비전 7 [까지] 얻어야 할 변경점을 계산하고, 이 변경점 들을 나의 워킹카피(브랜치 B나 트렁크)로 적용한다.

  리비전 범위를 비워둔다면, 서브버전은 올바른 리비전 범위르르 계산하기 위해 머지-추적 기능을 이용한다. 이것은 자동머지나 reintegrate 로 알려져 있다.

두개의 다른 트리를 머지

  이것은 reintegrate 방법보다 더욱 일반적인 경우입니다.서브버전에게 이것을 어떻게 행하는지 물어 보면: " 트렁크의 head 리비전 [부터] 브랜치의 head 리비전 [까지] 얻어야 할 변경점을 계산하고, 이 변경점 들을 나의 (트렁크의)워킹카피에 적용한다. 최종 결과로 트렁크는 브랜치와 완전 동일하게 보이게 된다.

  만약 당신의 서버/저장소가 머지-추적을 지원하지 않는다면 브랜치를 트렁크로 머지하는 유일한 방법이다. 다른 사용예는 벤더 브랜치를 사용할때 발생하고, 당신은 새로운 벤더를 뒤 따르는 트렁크 코드의 변경점을 머지해야 한다. 더 자세한 정보는 서브 버전 책의 "벤더 브랜치" 챕터를 읽기 바란다.

---

요거 아래로는 세부 내용이니 일단 패스

[링크 : https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-merge.html]

이것저것 테스트 해봤지만..

그래도 .bashrc에다가 cd 하나 넣어 주는게 젤로 편하긴 하네..

d 드라이브로 바로 bash를 실행하는 방법

[링크 : http://superuser.com/.../how-do-i-change-the-default-startup-directory-in-cygwin]

[링크 : http://stackoverflow.com/.../open-cygwin-at-a-specific-folder]

[링크 : http://unitstep.net/blog/2009/05/16/open-cygwin-bash-shell-here/] open with bash here

멀 하면 좋을까...

흥미를 잃은.. 라즈베리?

아니면.. 나중을 위한 atmega 라이브러리 화?

흐음....

particula

여전히 평가는 종합적(그렇지만 전부 부정적)

끝은 참 빠르다..

이번달은 한것도 없이 또 한달 지나가는구나...

-j 로 잘못하다가는 시스템 멈춤까지 가는데..

그걸 방지하기 위해 -l 옵션을 쓰는 것도 방법

기본값은 제한없음이니 적당히 설정해두면 좋을지도?

[링크 : http://korea.gnu.org/manual/4check/make-3.77/ko/make_5.html]

의존성을 줌으로서

병렬 빌드시 모든 파일이 준비되어야 하도록 해주어야 함

여기서 미묘한 점이 있는데 직렬 질드에서는 make 가 application 의 의존성 목록에서 왼쪽에서 오른쪽으로 작업을 시작할 것입니다. 첫번째로 ${OBJECTS} 의 모든 오브젝트들을 빌드 하고 나서 menu.o 를 빌드하는 규칙을 적용할 것입니다. 이러한 직렬 환경에서는 문제가 없습니다 왜냐하면 menu.o 가 처리될때 필요한 ${OBJECTS} 의 모든 오브젝트들은 이미 제자리에 있을 것이기 떄문입니다. 그러나 병렬 빌드에서 make 는 병렬 환경에서 모든 의존성들을 처리할 수 있으므로 menu.o 의 생성과 컴파일은 모든 오브젝트 들이 준비 되기 전에 시작 될 수 있습니다. 

[링크 : http://blog.syszone.co.kr/2099]

+

[링크 : http://forum.falinux.com/zbxe/index.php?document_srl=405822&]

[링크 : http://korea.gnu.org/manual/4check/make-3.77/ko/make_toc.html]

보니까 몇회차 엔딩이 있어서 다하게 될진 모르겠지만

아마도.. 1회차만 하게 될 기분?

번개가 치는 맵인데

번쩍하면 숨겨진 블럭이 있다 ㄷㄷㄷ

번개칠때 큐브를 먹어서 ㅋㅋㅋ 먼가 미묘한 기분

첫! 안티큐브!

음.. 이거 하고 조금더 했으니.. 40% 찍었겠지?

돈..

시간..

자아..

결혼에 있어서 어짜피 돈 vs 시간 되에는 답이 없지만

두개는 대개 반비례..

급여가 많으면 좋겠지만..

그렇다고 시간이 전혀 없어지면

내가 추구하던

돈 벌어 오는 아빠가 되지 않겠다는게 헛수고..

그렇다고 지금 벌이로는.. 후... 어렵다..