최근에는 본의 아니게 git을 사용하고 있습니다.
http://en.wikipedia.org/wiki/Git_(software)


git에 대해 잘 정리되어 있는 곳은 다음과 같이 많지만...

http://excess.org/article/2008/07/ogre-git-tutorial/
http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html

제가 주로 사용하는 커멘트 셋 정리를 해 보면 다음과 같습니다.

git 클론 생성


소스 업데이트


소스 수정
ps. git add를 따로 하지 않고 한번에 git add . 와 같이 해도 되지만 찌끄러기들도 같이 들어가서 짜증이 날 때가...

머지 에러시! 롤백하기.
ps. 물론 수정한 소스는 어딘가에 보관하고 있어야겠죠.

누락되거나 건드렸나 등의 상태확인

ps.
아직 잘 쓰지 않아서 불편함이 많지만,
좀 익숙해지면 다른 툴들과 장단점을 비교해 봐야겠습니다.

아놔... 심장 떨어질 뻔 했네요...

Visual Studio 2005와 Rational ClearCase의 합작 버그...

재현>

library1을 vs2005(#1)에서 작업한다.

이 library1을 사용하는 project로 또 하나의 vs2005(#2)를 열어 작업한다.

vs2005(#2)에서 디버깅모드로 진행하다가,
library1의 내부로 들어가서 소스 파일을 수정한다.
그리고 VS2005(#2) 상에서 모두 다 저장하면...?

vs2005(#2)에서 해당 library1에 관련된 파일명을 모두 소문자로 바꿔서 저장해 버린다.
그러면 ClearCase에서는 해당 파일을 못찾는 어이없는 사태 발생...
(해당 파일을 당근 리눅스에서도 역시 못찾음...)


크게 문제가 생기지는 않겠지만, "???"표가 ClearCase 상에서 뜨면 순간 엄청 놀라게 됩니다.
기껏 작업한 파일이 날라간 것으로 착각하는 사태 --> 심장에 압박 크리가 발생하게 됩니다.

vs2005(#1)에서 해당 파일을 열어서 다시 저장하면 해결되긴 하네요. -,.ㅡ;


ps. vs2005 2개에서만 발생하는지 1개에서도 동일하게 동작하는지는 잘 모르겠네요. 귀차니즘 --;

태그 : msvc8 , vs2005 , clearcase , rational , 버그

일반적으로 cppunit을 이용해서 test case(이하 TC)를 작성할 때,

우리는 아무 생각 없이 본능적으로 TC를 작성한다...
(음.. 나만 그런가?)

여러 실수들이 나올 수 있지만 그 중에서도 제일 황당한 경우를 소개한다 --;

나는 TC를 짜면 linux와 windows에서 모두 돌려보는데,

linux에서는 돌아가고, windows에서는 안 돌아가는 이상한 경우를 만났다.

물론, 내가 os의 차이를 제대로 반영 못한 것이라고 생각했었다.

그러나 아무리봐도 오류를 찾을 수가 없는 것이었다.

'이런 ㅅㅂ --+, 무슨 버그길래 이렇게 안 나오는거쥐'라고 생각하며 디버깅을 하는데,

반나절이 지나도 안 잡히는 거다 --+

나중에 여러 실험을 통해 결론은 내린 것은...

바로... cppunit이 linux와 windows상에서 아주아주~ 약간 다르게 동작한다는 것... --; (허탈...)

linux에서는 TC를 등록한 순서대로 테스트가 수행되지만,

windows에서는 알파벳 순으로 소팅이 되는 것이다.

정확히 이야기하면 windows에서도 cppunit(d).lib만 쓸때는 괜찮은 것 같고,

testrunner(d).lib를 쓰면 이런 어이없는 현상이 나타나는 것 같다.

(아니면 내가 일하는 데서 만든 cppunit의 wrapper즈음 되는 친구가 잘못하는 것일 수도 --+
사실 이 확률이 제일 크다!! 그럼 나와 다른 환경의 분들은 모두 낚이는 거~ ㅎㅎ)

즉, 이런 현상은 TC 이름이 이런 경우에 나타날 수 있겠다.

TC_Overall_Init
TC_01
TC_02

위와 같은 TC가 있고, TC_Overall_Init이란 TC는 본의 아니게 제일 먼저 테스트 되어야 하며,
TC_01, TC_02는 TC_Overall_Init의 결과를 토대로 동작한다고 가정한다.

이 경우 linux에서는 등록된 순서대로 동작을 하는데,
windows에서는 제일 나중에 수행될 수 있다는 것이다.

고로 본인은 TC_Overall_Init을 TC_00으로 수정해서 그냥 패스 시켰다 --;

이 현상이 msvc 6.0에서만 나고, .Net에서는 안 나는지는 모르겠다.

나는 msvc 6.0으로만 테스트 해 봤으니 알수 없다... 귀차니즘 발동...


ps. 이 현상에 대해 더 자세한 사항을 알고 있는 분은 좀 알려주세요~

회사에서 코딩 스탠다드의 압박으로 인해 beautifier를 찾아 보았다.

bc, indent님은 c를 대상으로 하는 것이니 패스~

그럼 무료중에 이름 좀 있다는 것 중에 남는건 bcpp 밖에 안 보이더군.

일단 설치해서 써 봤는데, 원하는 바에 비해 옵션으로 줄 수 있는게 많이 부족하네. --;

빵빵하고 공짜인 beautifier가 어디 있는지 아는 분 없나요?


ps. 쩝. 코딩 스탠다드의 취지를 알기야 하지만, 코딩도 내 나름대로의 개성인데 왜 틀에 껴 맞추려고 하는지...
    사실 se 입장에선 해야되는 거지만~  개발자 입장에서 보면 se는 역시 귀찮은 일이야 --+

블로그에 쓸게 없으니 별걸 다 쓰게 된다...

이런거 안 쓰자 주의 였는데 결국 쓰게 되는군하...

어떤 부서에서 우리가 만든 library에 대한 test coverage를 체크 한다는데,

안전빵으로 미리 체크해 보는 차원에서 gcov로 미리 test coverage를 체크해 보았다.

처음 써보는 툴(?)이므로 아래 사이트에 가서 잠시 공부한 후...

http://korea.gnu.org/manual/release/gcov/gcov_1.ko.html

쓰는데, 생각보다 잘 안되더군 ==;

써 있는 데로 대충 했는데, "undefined reference __gcov_merge_add " 어쩌고 저쩌고 하는 에러님이 마구마구 나오시는 것이 아닌가...

한참을 해메다 보니 테스트 프로그램 컴파일 옵션에 -lgcov를 안 붙인것 이었음 ㅡ,.ㅡ;

아 쪽팔려라... 시간 아까비...


ps. 그리고 테스트 프로그램님이 나뉘어 있는 경우에는 좀 집계 내기가 불편한 감이 있었다...