팀원에게 강제로 이슈트래킹을

다즐링의 이미지

역시 널리 알려진 팁입니다만 기록차 남겨둡니다.

trac과 subversion 은 강력한 조합입니다. 다만 익숙하지 않은 사람들에게는 매우 힘든 조합이죠 ㅠㅠ
여러 개발자들과 개발을 했습니다만 아직까지도 메신저로 파일을 주고 받는 사람들이 많은 시점에 -_-;;;
svn 을 익숙하게 하는데 엄청난 시간이 걸렸습니다. ( 익숙해지니 프로젝트가 끝나는.. )

프로젝트를 끝내고 생각해보니 이제 팀원들이 svn은 익숙한데 기껏 깔아둔 trac은 무용지물이 된것이죠.
겨우 소스 브라우징용도로만 사용되고.. 문서화는 스프링노트로 하게 해두었더니 trac에는 반영이 안되고..;

그래서 필요한것이 티켓넘버를 입력하지 않으면 커밋이 안되게 하는 후커입니다.
( 오래전부터 알고는 있었지만.. 이걸 차마 적용해야하나 라는 그런... 애매함이 급박한 상황이 되니 사라지더군요 )
추천해주신분은 대단히 뿌듯해 하시고..;;

trac 0.11 버젼 기준으로 우분투에 깔린 것을 사용하였습니다.
여러가지 문서에는 trac내에 있다고 했는데 못찾아서 그냥 소스를 받았습니다.
파일 첨부로 넣어두었으니 2가지 파일을 아무데나 복사합니다. trac소스내도 괜찬고 위치야 뭐..;

svn repo 내의 hooks 디렉토리에 파일을 2개 만듭니다.

pre-commit

#!/bin/bash
 
REPOS="$1"
TXN="$2"
TRAC_ENV="/var/lib/trac/secmem/"
LOG=`/usr/bin/svnlook log -t "$TXN" "$REPOS"`
/usr/bin/python /var/lib/svn/secmem/hooks/trac-pre-commit-hook "$TRAC_ENV" "$LOG" || exit 1

post-commit

#!/bin/bash
 
 
REPOS="$1"
REV="$2"
TRAC_ENV="/var/lib/trac/secmem/"
 
/usr/bin/python /var/lib/svn/secmem/hooks/trac-post-commit-hook -p "$TRAC_ENV" -r "$REV"

당연히 제일 마지막줄에 있는 위치는 알아서 변경해주시고 trac의 깔린곳을 설정합니다.
그리고 hook 에 실행권한을 줍니다.

chmod 755 pre-commit post-commit

이제 설정은 완료가 되었습니다.

커밋시에는 다음과 같이 메시지를 입력합니다. ( trac-post-commit-hook 에 설명되어 있습니다 )

명령어 #1
명령어 #1 , #2
명령어 #1 & #2
명령어 #1 and #2

명령어에 따라 #1 과 #2 티켓을 처리한다는 이야기입낟.
명령어는 다음과 같습니다.

close, closed, closes, fix, fixed, fixes : 특정 이슈넘버를 닫습니다.

references, refs, addresses, re, see : 특정 이슈넘버에 상태를 남깁니다.

문서의 예에 보면 "Changed blah and foo to do this or that. Fixes #10 and #12, and refs #12." 와 같이 주석을 넣으면 #10번과 #12번을 닫고 #12번에 노트를 남긴다고 되어 있습니다.

간단히 설명을 하자면 커밋을 하기전에 pre-commit 후커가 발동을 합니다. 로그에서 관련 명령어와 이슈넘버가 있는지 확인합니다. 없으면 에러를 냅니다. ( 즉 이슈넘버를 커밋로그에 적지 않으면 커밋이 안됨 )
이슈넘버를 적고 커밋을 하면 post-commit 후커가 발동을 합니다. 로그를 보고 trac에 업데이트를 합니다.

위의 후커들을 적용하면 반드시 다음과 같이 작업을 해야합니다.
1. 이슈를 생성한다. 혹은 이슈가 있는지 확인
2. 커밋시에 커밋로그에 이슈넘버를 반드시 입력해야한다.

이슈를 안적으면? 다음과 같은 일이 벌어진다.

secmem@exbi:~/rails$ svn commit -m "hahaha"
전송중         config/database.yml
파일 데이터 전송중 .svn: 커밋이 실패하였습니다:
svn: Commit blocked by pre-commit hook (exit code 1) with output:
At least one open ticket must be mentioned in the log message.

학생들과 프로젝트를 하다보니 강제적으로 뭔가 시켜야겠다는 마음보다는 좀 더 자유롭게 놓아두다가 여러번 말아먹었습니다. 뭐 몇번 할일이 없긴하지만 저 조차도 강제적으로 관리를 해야겠다는 마음이 드는군요 ㅠㅠ

File attachments: 
첨부파일 크기
Package icon trac-hooks.zip4.23 KB

댓글

vj1974의 이미지

어느 회사인줄은 모르겠지만 직원들은 힘들겠군요.

다즐링의 이미지

엥??

학생입니다만 -_-;;;;

커밋로그를 적는건 프로그래머가 아니라도 기본이라고 생각합니다만...

제가 잘못된건가요?

그리고.. 아직 cvs 를 쓰는거보다는 나을꺼라고 생각중입니다.

물론 hg 나 git 도 좋긴하지만.. 애들이 더 힘들어해요 ㅠㅠ

( 저야 씁니다.. )
------------------------------------------------------------------------------------------------
Life is in 다즐링

------------------------------------------------------------------------------------------------
Life is in 다즐링

sangwoo의 이미지

잘못된 거 절대로 아닙니다!
커밋 로그에 'fixed a problem' 이렇게 적는 사람 보면 때려주고 싶어집니다.
----
Let's shut up and code.

----
Let's shut up and code.

jick의 이미지

fixed a problem 정도면 양반이죠.

a.c를 커밋하면서 커밋 로그에 "a.c"라고 적는 분도 봤습니다.

peecky의 이미지

Q: 커밋 로그에는 무얼 적으면 되나요?
A: 자신이 무엇을 수정했는지 간단히 적으세요.

...

Q: 저는 a.c를 수정했습니다.

sangwoo의 이미지

오...
----
Let's shut up and code.

----
Let's shut up and code.

hongyver의 이미지

하도 로그를 안쓰길래...강제로 스크립트를 적용했더니...
이제 딸랑 a 자 하나 적어놓아요...
커밋로그 보면...
a 만 수두룩. 게다가 일괄 커밋을 하면 될껄....하나하나 커밋해서...revision 번호만 늘려놓고...자기코드니 건들지 말래나?

가끔 보면 자기실수를 a 만 써놓고 그냥 덮기도...

--------------------------------------------
오토바이 타는 개발자
홍가일보 편집장 홍가이버

bookworm의 이미지

제가 직원이라면 형상관리 도구와 이슈 트랙커를 사용하지 않는 회사는 가급적 지원하지 않을 것 같습니다.

--

B/o/o/k/w/o/r/m/

B/o/o/k/w/o/r/m/

academic의 이미지

????

강제로 특정 조합을 강제하지 말라면 뭐하라는 건지...

더 좋은 조합이 있으니 그걸로 강제하라는 것도 아니고...

--
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.

----
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.

jinhoy97의 이미지

절대, 그리고 반드시 코드를 올릴때 로그를 남기는 것은 기본입니다.
어떠한 것이 되든지 무엇이 되든지. 저는 올리지 않는 팀원들에게는
귀찮아 죽을 때까지 메일을 써댑니다.

근거나 기록을 남기지 않고 일을 계속하느니 그냥 관계를 끝내는게
더 '인간'적이라고 생각한다면 좀 너무 할까요? 솔직히 저는
그런 생각을 합니다.

특정 조합이든 뭐든 '근거'를 남기는 것이 중요합니다. 근거를
남기지 않는 동료라면 둘중 하나일 것입니다. 일하는데 폭탄을
숨기거나 아니면 정말 생각한대로 당장 해야 직성이 풀리는
사람이거나.

나는오리의 이미지

커밋 로그를 남기는것은 커밋하는 사람의 의무이죠.

superwisdom의 이미지

저는 hooks 스크립트에 메일 발송 + indent 적용 + trac 연동만 등록하여 사용하고 있었습니다만, 강제할 생각은 (감히) 못해봤습니다.
내일 한 번 적용해 봐야겠군요. 마침 새 프로젝트가 시작하려고 하니, 건의해 봐야겠습니다. (내가 언젠가 PM이 되면 다즐링님처럼 강제해야지. ㅋ)
문서화도 trac wiki를 이용하면 좋을것 같은데, 문서 템플릿이 중요하다고 생각하는 어르신들 때문에... 걍 비공식 산출물에만 이용하고 있다는...

다즐링의 이미지

정말 필요한 산출물만 필요한 나라(?) 가 되었으면 좋겠습니다.. ㅠㅠㅠㅠㅠㅠㅠㅠㅠ

위키 정리하고 이중정리하는 이런거 정말.. ㅠㅠ

------------------------------------------------------------------------------------------------
Life is in 다즐링

------------------------------------------------------------------------------------------------
Life is in 다즐링

다즐링의 이미지

그리고 trac 에서 code review 를 해야 커밋이 가능한 hack 도 있다던데...

아직 거기까진 필요하지 않아서 넣치 않았습니다.

------------------------------------------------------------------------------------------------
Life is in 다즐링

------------------------------------------------------------------------------------------------
Life is in 다즐링

creativeidler의 이미지

예전에도 한 번 언급한 바가 있는데 커밋에 여러 가지 제약을 두면 커밋을 자주 안하게 됩니다. SCM의 의미가 퇴색하는 것이죠. 전 하루에도 수십 번씩 커밋하는 상황이 더 바람직하다고 봅니다. 작은 변경이라도 팀원들과 공유해야 문제점을 빨리 찾을 수 있죠. 그런데, 커밋할 때마다 뭔가 부가적인 작업을 해야 한다면 커밋을 하루에 한두 번으로 줄이게 될 겁니다. 좋은 상황이 아니죠.

제약은 릴리스에만 두면 됩니다. SCM의 목적은 원활한 공동 작업에 있는 것이니 작업이 완료되지 않았더라도 필요에 따라 커밋을 하면서 작업을 해야 그 힘을 제대로 발휘하는 것입니다.

한 가지 더 첨언하면, 커밋과 이슈를 연계시키는 trac은 경험상 마이크로 매니지먼트의 문제점을 발생시키는 경우가 많습니다. command & control보다는 더 나은 방법이 많이 있을 것입니다.

neogeo의 이미지

개인적인 부분을 커밋하는건 하루에도 수십번이라도 하는게 옳지만,

'작은 변화라도 팀원과 공유' 를 위해 하루에도 수십번 커밋하는건 그다지 효율이 없다고 생각합니다.

팀원 여러명이 누군가 올린 조그마한 커밋( 하루에 수십번 커밋이라면 커밋 단위가 굉장히 작겠죠 )의 change log 를 보면서 코드를 들여다 보다가 버그를 발견했다고 칩시다.

그런데 점심먹고 돌아와서 버그를 알려줄려고 하던 도중, 다른 팀원이 또 발견해서 버그를 알리고 수정하라고 해서 그 사이에 ( 하루에 수십번 커밋할 정도면 코드가 몇백줄 짜리 이내일껍니다. 그래서 간단히 처리가 되었겠죠 ) 커밋했던 사람이 수정했습니다. 자 그럼 두 팀원은 같은 코드를 보며 같은 버그를 발견했지만, 결과적으로 둘중 하나의 시간은 허공에 날린게 되었습니다.

1. 여러 팀원이 하루에 수십번 커밋하는 내용을 일일이 도중에 체크한다는건 엄청난 시간낭비 입니다.
2. 체크하는 도중 문제가 발견되어 수정하더라도 다른 수정된 내용을 보기도 전에 혹은 보는 도중에 고쳐진게 되어 시간 낭비를 할 공산이 큽니다.
3. 작은 단위로 커밋 한다는 것 자체가 무수히 많은 버그를 양산할 공산이 큽니다. 또한 작은 단위의 수정때마다 같은 파일을 고친 팀원이 모여 merge 해야하는데 모았다가 하는게 훨씬 시간적으로 낭비가 적습니다. 프로그래머는 업무에 대한 context switching 비용이 매우매우 큽니다.

따라서 이상적으로는 test driven 상황을 만들고 auto test 를 돌려 하루 정도 단위의 코딩 작업후, test를 통과했을때만 commit 하는게 정석같습니다. 최소한의 기본적인 테스트는 넘어가게 해둬야 팀원끼리 서로의 시간을 낭비하는 일이 적어지지요.

아침에 브레인 워밍업으로 밤사이에 팀원들간에 commit 된 코드를 들여다 보며 뭐가 바뀌었나 커피 마시며 확인한뒤 또 하루 종일 자기 작업에 매달리게 하는게 가장 효율적인것 같습니다.

작은 변경이라도 팀원들과 공유해서 문제점을 빨리 찾을 수 있는것 같지만, 문제점을 찾기 위해 들이는 시간낭비가 엄청 비효율적이 되어서 문제만 찾다가 업무 진행을 전혀 하지 못할지도 모릅니다. 물론 프로젝트 아주 초창기에는 서로 의견을 통일시켰어도 코드 내용을 들여다 보면 또 달라질게 있기 때문에 하루에 여러번 커밋해가며 의논하는 쪽이 옳을지도 모릅니다. 그러나 어느정도 기본적인 뼈대의 디자인이 진행된 상황이면, 그리고 초기의 1,2 달 코드가 다 끝난뒤라면 각자 하루에 수십번 커밋해가며 코드를 통일시키는건 상당한 시간소모적인 일이 될 공산이 크다고 생각합니다.

개인 repository , 팀 repository , develop branch , release branch 등을 다 구분하여 항상 작업의 시작은 release branch 로 부터 하고 issue 가 있을경우 팀원들이 협의하여 되도록 빨리 release branch 에 적용하게 하는게 가장 현명한것 같습니다. 그리고 항상 release branch 에 commit 하기 전엔 review 를 다 통과한 녀석이 되어야 겠지요.

Neogeo - Future is Now.

Neogeo - Future is Now.

marzok의 이미지

모든 팀원이 동일한 환경을 가지고있고
코드 수정과 빌드가 동시에 이뤄지고
프로젝트 그 어느 곳에도 빨간 불이 없는 상황이면
이제까지 작업한 내용을 통째로 수시로 커밋을 합니다.

이렇게 되면 모든 사람들이 자기 프로젝트에 단 하나의 빨간 색도 용납을 안하는 습관을 갖게 됩니다.
어디든 빨간 불이 나오면 불 끄기를 먼저 진행하고 불이 다 꺼지면 통째로 커밋을 합니다.

따라서 따로 통합을 할때 부담이 없습니다. 언제나 통합이 되어있습니다.

그리고 툴을 강제하기 보다는 사람들이 쓰기 편하게 해주는 방법을 선호합니다.
그 모든 사용법을 다 알려주려 하지 않고 그냥 대충 따라 써도 되게 환경을 만들어 줍니다.
일예로 위와 같은 상황이면 eclipse+mylin+jira+svn 이렇게 연결해서
사람들이 수용 가능한 만큼만 사용하게 합니다.

이후에 사용법이 익숙해지면 기능을 하나씩 더 배워 나가는 방향으로 진행을 합니다.

다즐링의 이미지

저도 그런 이상적인 상황이면 제약을 걸지 않겠습니다. ㅠㅠ

테스트가 뭔지도 모르고 관련 코드를 작성하지 못한다면... 힘들죠 ㅠㅠ

------------------------------------------------------------------------------------------------
Life is in 다즐링

------------------------------------------------------------------------------------------------
Life is in 다즐링

roylory의 이미지

.

roylory의 이미지

저도 회사 내에서 지나치게 잦은 커밋은 별로라고 생각합니다.

개발자들이 전세계에 흩어져 있는 것도 아니고, 같은 회사에서 붙어서 개발하고 있는 장점을 충분히 살릴 필요가 있죠. 사소한 버그를 발견하면 담당자에게 고치라고 말로 하는게 깔끔하죠.

매일 얼굴보고 사는 사이인데, 내 맘에 안든다고 매번 코드를 뜯어고쳐서 올리기도 그렇고...

저는 윗분 의견에 대찬성입니다.

자주 커밋하고 싶은 개발자는 Git + SVN 이 좋은 대안일 수 있을것 같습니다.

creativeidler의 이미지

>1. 여러 팀원이 하루에 수십번 커밋하는 내용을 일일이 도중에 체크한다는건 엄청난 시간낭비 입니다.

위와 같은 내용을 쓰셨는데, 커밋하는 내용을 일일이 체크해야 하는 어떤 이유가 있나요?

neogeo의 이미지

'공유를 위해서' 수십번 커밋한다고 하셨으니까요. 커밋 된 내용을 무시할 거면 애초에 '공유를 위해서'라는 말이 아닌게 되는거죠. 그저 개인소스 작업내용을 시간별로 기록하고 싶은 수준밖에 안되지요.

적어도 자신이 커밋하기 전에는 누가 커밋했나 check 정도는 해봐야겠죠. 그리고 작업내용이 공유 되는 순간 내가 작업한 내용이 컴파일이 될 확률은 .... 글쎄요 상황에 따라 다르겠죠?

자신이 커밋할 소스가 어떤 영향을 줄지 그 작업한 사이에 수십번 커밋이 되어있을테니 적어도 log 정도는 살펴보고 관련 내용이 있으면 소스도 한 번 들여다 봐야겠지요...

Neogeo - Future is Now.

Neogeo - Future is Now.

creativeidler의 이미지

여러 팀원이 하루에 수십번 커밋하는 내용을 일일이 도중에 체크한다

적어도 자신이 커밋하기 전에는 누가 커밋했나 check

는 다릅니다.

공유를 위해서 커밋한다는 게 커밋할 때마다 다 보라는 게 아니고 자기도 잦은 커밋을 하다보면 자연스럽게 확인이 되는 것입니다.

그리고, 체크랄 게 뭐 있나요. 어차피 업데이트 받아서 테스트 한 번 돌려보면 되는 건데.

neogeo의 이미지

test fail 이 안난다는 보장이 안되지요. test success 까지 확인 하는것 자체도, 그걸 하루에 '수십번' 한다는게 엄청난 시간 낭비라는거죠.

작업 다하고 한번 하는것과 수십번 하는건 엄연하게 엄청난 시간 낭비입니다. ( 2분씩만 걸린다고 해도 말이죠. )

그리고 위에 글을 충분히 썼지만, 프로그래머가 컨텍스트 스위칭 하는 비용은 엄청납니다. test fail 이 났을때 남의 코드를 안들여볼 수 없게 되겠지요? 그걸 하루에 수십번 한다면?( 머리속에 자기 코드 이외에 남의 코드를 이해하려고 읽는 순간 상당수의 캐쉬가 miss 나지요? :) )

그리고 자연스럽게 확인이라는게 무슨 의미 인지 잘 모르겠지만, svn 정책상 자기가 업데이트하기 전에 같은 소스를 고쳤으면 남이 고친 부분을 merge 해야만 commit 이 되는게 정상인데, 어떻게 자연스럽게 확인 된다는건지 잘 모르겠습니다. 더군다나 하루에 수십번 commit 한 내용중에 개인이 roll back 하는 부분이 전혀 없을거 같은가요?

내가 되돌리고 싶은 코드 혹은 이부분 커밋 부분을 다시 지우고 싶어도 그 사이에 여러 사람이 수십번씩 commit 하고 있는 상황중이면, 또 코드를 지우는데 다시 작업 해야만 합니다.

그리고 그동안 작업된 로그를 살펴보지 않는 것도 ( svn ) 소스 공유를 위해 commit 한다는것과는 아주 거리가 멉니다. test case 만 돌리고 commit 하는게 설마 소스 공유를 하는 거라고 생각하신다면, 뭔가 잘 못 생각하고 계신다고 말씀드리고 싶습니다. test case 만 돌리고 commit 하는건 개인의 repository 에서나 해야할 일입니다.

하루에 수십번 source 의 commit 을 하면

- 같은 소스를 건드리는 곳은 commit 할때마다 crash 가 납니다. ( 모든 사람이 수십번씩 commit 하고 있으니까요. ) -> 남이 고친 부분과 로그를 들여다 보지 않고는 merge 할 수 없습니다. -> 그게 남의 소스코드를 살펴보고 check 해야만 하는 이유 입니다. 안살펴볼 방법 자체가 없지 않나요? merge 를 설마 기계식으로 diff 떠서 그냥 자동으로 되면 넘어가게 하는건 아니겠지요?

Neogeo - Future is Now.

Neogeo - Future is Now.

creativeidler의 이미지

1. 전 테스트를 하루에 수백 번 이상 돌립니다. acceptance test는 시간이 많이 걸리기 때문에 전체 테스트를 돌리는 건 하루에 10회를 잘 안 넘지만 unit test는 대부분 10초 안에 결과가 나오기 때문에 부담 없이 그냥 누릅니다. 그냥 이건 습관 같은 거라서 커밋 안해도 늘 확인하는 행동이지요. 간혹 autotest 프레임웍을 쓰는 경우도 있는데 이 때는 업데이트 받자마자 결과가 표시됩니다.

2. 하루에 수십 번 커밋한다고 할 때마다 업데이트 사항이 있지는 않습니다. 커밋 내용이 누적 반영되어서 오기 때문에 다른 사람이 10번 커밋했다고 해서 내가 10번 업데이트해야 하는 것은 아니지요. 내가 하루에 30번 커밋한다고 해도 다른 사람의 소스 코드를 봐야 하는 경우는 10번을 넘지 않는, 그 정도 비율입니다.

3. 커밋할 때는 제 입장에서는 일련의 작업이 완료된 이후입니다. 컨텍스트가 이미 종료된 이후지요.

4. 같은 소스를 고치는 경우는 그다지 흔하지 않습니다. 수십 번의 커밋 중에 한두 번 정도? 페어를 많이 하는 팀의 경우라면 작업 유닛의 숫자가 반으로 줄기 때문에 더더욱 같은 소스를 고칠 확률이 줄어들죠.

5. 테스트 케이스만 돌리고 커밋하는 것은 개인 리파지토리에서나 할 일이다? 헐, 절 학생 취급 하시는 건가요? 이런 말은 좀더 조심해야 하지 않을까요. 그럼 제가 질문 하나 드리죠. 당신의 팀은 daily release를 고객에게 직접 할 수 있을 만큼 defect free한가요?

neogeo의 이미지

5. 테스트 케이스만 돌리고 커밋하는 것은 개인 리파지토리에서나 할 일이다? 헐, 절 학생 취급 하시는 건가요? 이런 말은 좀더 조심해야 하지 않을까요. 그럼 제가 질문 하나 드리죠. 당신의 팀은 daily release를 고객에게 직접 할 수 있을 만큼 defect free한가요?

학생취급한적도 없으며, 제가 속한 팀은 회사의 daily release 를 고객에게 직접 할 필요가 없는 회사입니다. 논의 자체가 논점일탈의 오류이십니다. 상대방의 말에 근거해서 반박을 해주시기 바랍니다. test case 통과만으로 commit 한다는 방식이 개인 repository 에나 어울리는 정책이라고 의견을 드린것 뿐입니다. 무슨 근거로 학생취급한다고 생각하시는지 말씀해주시기 바랍니다. 더불어 학생취급이 무슨 의미인지는 모르겠지만 의견을 말하는데 있어서 상대방을 경시해서 의견을 내놓은적은 없습니다.

1. 전 테스트를 하루에 수백 번 이상 돌립니다. acceptance test는 시간이 많이 걸리기 때문에 전체 테스트를 돌리는 건 하루에 10회를 잘 안 넘지만 unit test는 대부분 10초 안에 결과가 나오기 때문에 부담 없이 그냥 누릅니다. 그냥 이건 습관 같은 거라서 커밋 안해도 늘 확인하는 행동이지요. 간혹 autotest 프레임웍을 쓰는 경우도 있는데 이 때는 업데이트 받자마자 결과가 표시됩니다.

-> 전체 test 를 하지 않고 unit test 만으로도 팀전체 branch 에 source 를 commit 하시는 상황이라고 이해해도 되겠습니까? ( 물론 항상 그런다는 의미가 아니라 일부 그렇다는 이야기 입니다. )

2. 하루에 수십 번 커밋한다고 할 때마다 업데이트 사항이 있지는 않습니다. 커밋 내용이 누적 반영되어서 오기 때문에 다른 사람이 10번 커밋했다고 해서 내가 10번 업데이트해야 하는 것은 아니지요. 내가 하루에 30번 커밋한다고 해도 다른 사람의 소스 코드를 봐야 하는 경우는 10번을 넘지 않는, 그 정도 비율입니다.

-> 다른 사람이 10번 커밋한게 나에게 10번 update 해야한다는 의미로 말한게 아닙니다. 다른 사람이 수십번 한다면 본인도 수십번 하는 것이고 수많은 사람이 할수록 내가 commit 하려고 할때마다 update 해야할 확률이 높아진다는겁니다. 즉 결과적으로 commit 할때마다 update 해야할 확률이 매우 높다는 것이지요. 틀린 가정인가요?

3. 커밋할 때는 제 입장에서는 일련의 작업이 완료된 이후입니다. 컨텍스트가 이미 종료된 이후지요.

-> 그런 상황에 하루에 수십번 커밋하신다는건 상당히 생산성이 높은것 같습니다. 존경할만한 프로그래밍 능력을 지니신것 같아서 매우 부럽습니다. 전 하루에 한번 commit 하기도 사실 매우 벅찹니다. ( 물론 개인 repository 엔 수시로 하겠지요. )

4. 같은 소스를 고치는 경우는 그다지 흔하지 않습니다. 수십 번의 커밋 중에 한두 번 정도? 페어를 많이 하는 팀의 경우라면 작업 유닛의 숫자가 반으로 줄기 때문에 더더욱 같은 소스를 고칠 확률이 줄어들죠.

-> 매우 행복한 상황이신거 같습니다. 같은 소스를 고치는 경우가 매우 드문경우라면 팀 브랜치에 수십번씩 커밋하는 것도 반드시 비효율적인건 아니라고 보입니다. 그러나 그렇다고 하더라도 팀 브랜치에 여러번 commit 하는 것 보단 하루에 1,2회 정도만 하는 정도가 좀 더 효율적이 될 확률이 높다고 생각합니다.

지금 상황이 전 분명히 애초부터 하루에 팀 브랜치에 수십번씩 커밋하는게 비효율적이라는 의견을 드린것입니다. 그것에 대해 학생취급 운운한적도 없으며, 팀의 운영 상황에 대해 딴지를 걸고 싶지도 않습니다. 얼마나 훌륭한 팀인가 따지는 것도 아니구요. 개인 repository 에나 어울리는 정책이라고 의견을 드리는 것입니다. 본인의 상황을 변호하는게 아니라 팀 브랜치에 수십번씩 커밋 하면 어떤 이점이 있는가 의견을 내주시는 편이 생산적일것 같습니다.

일단 저에게는 일반적으로 모든 팀원이 수십번씩 commit 하는게 효율적인지 다시 한번 생각해봐도 비효율적이라는 생각밖에 안드는군요.

Neogeo - Future is Now.

Neogeo - Future is Now.

creativeidler의 이미지

-> 전체 test 를 하지 않고 unit test 만으로도 팀전체 branch 에 source 를 commit 하시는 상황이라고 이해해도 되겠습니까? ( 물론 항상 그런다는 의미가 아니라 일부 그렇다는 이야기 입니다. )

네. 대신, 릴리스 브랜치를 만들 때는 항상 at를 다 돌립니다.

-> 다른 사람이 10번 커밋한게 나에게 10번 update 해야한다는 의미로 말한게 아닙니다. 다른 사람이 수십번 한다면 본인도 수십번 하는 것이고 수많은 사람이 할수록 내가 commit 하려고 할때마다 update 해야할 확률이 높아진다는겁니다. 즉 결과적으로 commit 할때마다 update 해야할 확률이 매우 높다는 것이지요. 틀린 가정인가요?

확률이 높아지는 것은 당연히 맞습니다만, 얼마나 높아지는가의 문제지요. 사람들의 시간대별 행동 패턴까지 감안하면 이론적으로도 계산할 수 있을 것입니다. 하지만, 그렇게까지 이론을 세워본 적은 없고, 경험적으로 커밋 회수의 20~30%로 업데이트가 필요하더군요.

-> 그런 상황에 하루에 수십번 커밋하신다는건 상당히 생산성이 높은것 같습니다. 존경할만한 프로그래밍 능력을 지니신것 같아서 매우 부럽습니다. 전 하루에 한번 commit 하기도 사실 매우 벅찹니다. ( 물론 개인 repository 엔 수시로 하겠지요. )

생산성 면에서는 잘 모르겠으나, 하루에 수십 번 커밋할 수 있을 정도로 문제를 작게 나눌 수 있다는 것은 저도 꽤 괜찮은 능력이라고 생각합니다. 아직 충분한 수준은 아니지만요.

-> 매우 행복한 상황이신거 같습니다. 같은 소스를 고치는 경우가 매우 드문경우라면 팀 브랜치에 수십번씩 커밋하는 것도 반드시 비효율적인건 아니라고 보입니다. 그러나 그렇다고 하더라도 팀 브랜치에 여러번 commit 하는 것 보단 하루에 1,2회 정도만 하는 정도가 좀 더 효율적이 될 확률이 높다고 생각합니다.

매우 드물지는 않습니다. 저희가 커밋하는 회수에 비해 드물다는 것이죠. ''하루''를 기준으로 보면 비율은 비슷할 겁니다. 하나, 전반적으로 개발에 관해서는 매우 행복하긴 합니다.

개인 리파지토리에서나 할 일이다...라는 말은 곧 제가 개인 리파지토리에서나 할 일을 팀에서 하는 사람이라는 얘기인 거 아닌가요? 이 정도면 꽤 인신공격성이 있는 말인데요.

저는 증거주의자입니다. 어떤 프랙티스가 좋은지 안 좋은지 최종적으로 증명해주는 것은 그 프랙티스를 실천하는 팀의 생산성입니다. 물론, 그것이 확정 증거는 아니겠지만, 이론적으로 따지는 것보다 좀더 쉽습니다. 이런 문제를 이론적으로 따지기에는 아직 소프트웨어 공학의 발전 수준이 부족합니다. 고려해야할 변수도 너무 많고 이론 정립이 안된 부분도 많죠. 그래서, 저는 적어도 정황증거로 쓸만한 거라도 놓고 이야기하자는 것입니다. 자꾸 비효율적이라는 말씀을 하시니 그럼 효율을 비교해봐야 하는 것 아니겠습니까?

물론, 그렇다고 이론적으로도 근거가 없다는 얘기로는 오해하지 마십시오. 이론적으로도 역시 확정 근거는 아니지만 여러 가지 확률을 높여주는 근거들은 많습니다. 일례로 린이 있겠지요. 린에서는 고객에게 전달되기 전의 재공품은 모두 재고라고 부릅니다. 재고는 적을수록 좋은 것이죠. 소프트웨어 개발에서의 재고는 무엇이 있을까요? 여러 가지가 있지만 LSD에서는 커밋하지 않은 코드도 재고로 분류합니다. 커밋하지 않은 코드라는 재고를 적게 유지하려면 자주 커밋하거나, 코드를 적게 만들거나. 아주 짧은 코드들로 시장을 만족시킬 수 있는 제품을 내놓을 수 있다면야 자주 커밋할 필요는 없겠지요.

neogeo의 이미지

Quote:

그리고 그동안 작업된 로그를 살펴보지 않는 것도 ( svn ) 소스 공유를 위해 commit 한다는것과는 아주 거리가 멉니다. test case 만 돌리고 commit 하는게 설마 소스 공유를 하는 거라고 생각하신다면, 뭔가 잘 못 생각하고 계신다고 말씀드리고 싶습니다. test case 만 돌리고 commit 하는건 개인의 repository 에서나 해야할 일입니다.

라고 말씀 드렸습니다. 뭔가 오해가 있으셨군요. 개인 리포지토리에서나 할 일을 팀에서 한다는 의미라기 보단 svn commit 로그를 살펴보지도 않고 소스공유를 한다는 의도로 commit 한다는건 개인 리포지토리에나 어울리는 정책이란 뜻입니다. 즉 어찌되었건 하루에 수십번 commit 한다는 상황을 비판하고 있는건 맞지만 팀 정책에 대해 비난하고 있는건 아닙니다. 앞뒤 문맥을 자르고 ( 작업된 로그를 살펴보지도 않고 commit 한다는 가정 ) 그 문장만 보시게 되면 다른 의도로 들릴 수도 있겠습니다만. 여하튼 저는 인신공격을 하기 위해 그런 의견을 낸것이 아닙니다. 기분이 나쁘시다면 사과드리겠습니다. 애초에 팀원들의 svn log를 살펴보지도 않는건 당연히 개인 repository 에 저장할때나 하는 행동이지요. 그게 아니라고 생각이 드신다면 뭐 할말이 없습니다만....

Neogeo - Future is Now.

Neogeo - Future is Now.

creativeidler의 이미지

저 그거 말한 거 맞는데요. 어쨋거나 저는 커밋 로그 보지도 쓰지도 않고 테스트만 돌리고 커밋하고 또, 팀원들에게도 그러라고 합니다. 이게 개인 리파지토리에서나 할 일이라면서요? 저를 개인 리파지토리에서나 하는 행동을 팀에 와서 하는 사람으로 몰고 있는 거 맞지 않습니까. 이런 걸 인신공격이라고 하는 겁니다.

물론, 목적은 말씀처럼 인신공격이 아니었는지도 모르지요. 하지만 표현이 문제인 겁니다.

반대로 제가 님의 글 내용을 두고 데이터도 없고 이론적으로 검증도 안된 이야기를 개인 블로그에나 적지 왜 남의 블로그에 토론하는데 와서 하냐고 하면 기분 좋으시겠습니까?

별로, 사과 받을 생각으로 지적한 건 아닙니다. 그저, 그런 표현은 인신공격성이 있다는 것을 인지하고 이야기하자는 겁니다.

neogeo의 이미지

뭔가 SCM 사용 목적에 대치되는군요.

SCM 에 로그를 전혀 보지 않고 , 쓰지도 않고 commit 해서 사용하기만 하는건 사용 목적에 굉장히 위배된다고 생각합니다.

인신공격이 아니라 정당한 논리라고 생각합니다만.....

팀워크의 공유라는 목적에 따르면, SCM 의 log 를 안다는 행위는 소스코드에 주석을 안다는 것과 매우 흡사하다고 생각 합니다.

그리고 그런 행위를 비판하는게 어떻게 인신공격이 되는지 이해가 되지 않습니다.

전 제글에 인신공격성은 전혀 없다고 생각합니다. 자의적으로 인신공격으로 해석하신거에 불과하다고 생각합니다만. 몰고 간적도 없고 그런 행위는 개인 리포지토리에 어울린다가 어떻게 인신공격이라는지 전혀 이해가 가지 않습니다.

그리고 토론의 장에서 자신의 의견을 다는게 잘 못 된겁니까? 뭔가 갈수록 삐딱하게 가시는군요.

인신공격성이 있었다는건 절대 인지하지 못 하겠습니다.

Quote:

반대로 제가 님의 글 내용을 두고 데이터도 없고 이론적으로 검증도 안된 이야기를 개인 블로그에나 적지 왜 남의 블로그에 토론하는데 와서 하냐고 하면 기분 좋으시겠습니까?

애초에 본인도 '어느정도만' 검증된 이야기를 남의 블로그에 토론하는데 와서 하신것 아닌지요? 그리고 토론하는데 있어서 비난이나 욕설을 하지 않는 이상 기분운운 해야할 이유도 모르겠습니다만....

더불어 제 글에 불쾌감을 느끼신다면, 이 글타래에 있는 'logging 하지 않으면 commit 도 하지 말라'는 의견에 전부 불쾌감을 느끼셔야 할 것 같습니다. 그쪽에 대해서도 인신공격이라고 인지하실 의향은 있으신지?

Neogeo - Future is Now.

Neogeo - Future is Now.

creativeidler의 이미지

>SCM 에 로그를 전혀 보지 않고 , 쓰지도 않고 commit 해서 사용하기만 하는건 사용 목적에 굉장히 위배된다고 생각합니다.

이렇게 주장하는 것은 아무 문제 없습니다. 이건 그냥 의견 차이일 뿐이니까요. 하지만 그렇다고 저런 행동을 '''개인 리파지토리에서나 할 행동'''이라고 표현하는 것이 인신공격이라는 얘깁니다. 이걸 이해하신다면 logging 없이 commit하지 말라가 왜 불쾌감이 안 느껴지는지 이해하실 수 있겠지요. 인신공격의 오류에 이어 확대해석의 오류까지 범하신 겁니다.

뭐, 저도 왜 자꾸 자신이 경험해보지도 못한 상황을 상상만으로 평가하는지 이해가 안되기는 합니다. 상상은 그냥 개인 일기장에다 쓰는 걸로 끝나도 될 텐데 말입니다.

neogeo의 이미지

공용적으로는 사용 목적이 위배 되니까 개인 리파지토리에서나 할 행동이 맞는것 아닙니까?

그리고 개인 리파지토리에서나 할 행동이라고 평가하는게 왜 인신공격입니까? 인신공격의 단어의 뜻이나 알고 계시는건지 궁금합니다. 개인 리파지토리에서는 어울리지만 팀 리파지토리에서 안어울리는 행동이라고 말하는게 인신공격이라면, 여기에 글을 쓰지말고 일기장에나 의견을 쓰라는 말도 똑같은 인신공격이겠군요. 개인 일기장에나 쓸 글글 여기다 쓰고 있다고 하시니까요. 그러나 저는 전혀 인신공격으로 느껴지지 않습니다.

그리고 제가 상상만으로 평가한다고 하시는데, 일반적인 상황에서 SCM 에 로그를 전혀 보지 않고 쓰지도 않는 행동은 분명히 잘못된 행위라고 주장하는겁니다. 그게 어디가 상상이 들어간건지 이해가 되지 않습니다.

분명히 제 '의견' 이지 상상이 아닙니다.

자신이 경험하지 못한일이라는건 무슨 뜻입니까? SCM에 제대로 로그를 달지도 않아서 프로젝트나 SCM 사용 case가 와해된 경우를 겪어봐서 이런이야기를 하는 겁니다.

본인이 멋대로 인신공격으로 확대해석 하고 계시며, 제가 여기에 의견을 다는건 제 자유 입니다.

끝으로 제가 했던 사과를 철회하겠으며(어차피 본인도 필요없다고 하셨으니), 저는 인신공격을 했다는 주장에 절대 동의 하지 않습니다.

Neogeo - Future is Now.

Neogeo - Future is Now.

marzok의 이미지

게시판 뎃글로 이야기를 하다보니 아무래도 좀 과열된거 같습니다.

다즐링의 이미지

일단 여러가지 상황에 대해서 적었어야 하는데 적지 못하였군요.

첫째로 지금 커밋을 않하게 된다고 이야기하시는 것은 빌드가 제대로 되는 소스를 커밋하는 즉 scm 을 제대로 사용 하는 사람들이 있다는 가정하에 이야기 하시는 듯 합니다.
저도 그렇게 일해왔습니다. 하지만 200개의 커밋로그중에 저만 커밋로그를 달고 update 하지 않고 소스를 받고 강제로 커밋하고 버젼이 이유 없이 낮아지고 하는 등의 일을 겪게되면
즉 scm 을 제대로 사용하지 못하는 그리고 의지가 없는 사람들과 일을 하게 된다면 어떨까요?

둘째로 일거리를 주는것이 아니라 본인이 직접 이슈를 적고 즉 자신의 문제를 적고 자신이 해결한다고 생각한다고는 생각않하셨는지요?
게다가 잘아시겠지만 이클립스의 플러그인등을 쓴다면 좀 덜 번거롭게 이슈트래킹 + 커밋이 가능하니까요
적어도 자신이 하는 일 정도는 적을 수 있다고 생각합니다.
그리고 커밋을 제약없이 여러번 하고 싶으시다면 git 나 hg 를 쓰시면 됩니다.

셋째로 모든 것이 애자일 해야된다고는 생각하지 않습니다.
그리고 애자일도 애자일 나름이지 않겠습니까? 적어도 신뢰가 기반이 된다면 가능한거겠죠

------------------------------------------------------------------------------------------------
Life is in 다즐링

------------------------------------------------------------------------------------------------
Life is in 다즐링

phg98의 이미지

좋은 practice를 팀원들이 잘 모르고 있고, 지켜지지 않는다면 잠시 강제로 적용시키는 것은
유용하다고 생각됩니다. 다들 익숙해지면 풀면 되겠죠. ^^

shkimstyle의 이미지

회사에서 ClearCase 를 official SCM으로 사용하고 있어서 여기에 BTS는 mantis 를 붙여서 사용했지요. commit 꺼리가 생기면 mantis 에 issue 하나 생성해서 해당 사항에 대해서 제목을 명료하게 적어내고, 내용을 자세하게 자기가 필요한 만큼 적으라고 했지요. 그리고 ClearCase에 commit 할 때 activity 이름을 mantis 제목을 붙이게 했습니다. 이를테면

007234 : [Multimedia] Apply JPEC codec for media gallary

이런 식으로 말이지요. (007234는 mantis 가 자동으로 붙여주고) 그런식으로 관리해서 나중에 integrator 가 code freeze 시작하고 deliver 하기 전에 commit 리스트 보고 저런 식으로 작성 안한 activity 는 deliver 안했습니다. 한달정도 안해버리고 뭐라 하면 프로젝트 리더한테 보고했습니다. 그렇게 6개월 지나니 모든 사람들이 알아서 하더라구요. 물론 그 이후에도 대략 넘어가려고 하는 사람들이 있어서 그냥 무시하고 deliver 안하고 했습니다. 1년 지나니까 BTS 내용도 충실하게 올리고 ClearCase commit 도 잘 합니다.

습관으로 정착하는데 1년가량 걸리는 것 같습니다. 이제는 BTS에 수정한 사유랑, 해당 수정사항(구현사항) 테스트 하는법 (나중에 테스트 팀이 regression 테스트함), 변경파일 (자동으로 Clearcase랑 mantis 랑 연동이 안되어, clearcase 에서 activity 당 change set 복사하기 해서 붙여넣음) 을 꼭 적어넣습니다. 다 하는데 10분도 안걸립니다. 길다구요? 나중에 삽질하는 시간이 훨씬 깁니다. 이런식으로 개발자는 자신의 코드 검토도 하고 좋죠.

이렇게만 하면 change note 정확하게 남고, 나중에 문제 생기면 디버깅 하기도 편합니다.

rainmon의 이미지

티켓넘버 확인과 입력이 귀찮을것 같네요. TortoiseSVN에선 커밋창에 이슈트래커와 연동되어서 티켓확인, 입력이 편리하고 보기도 좋아서 호응이 좋을듯 한데..(전 안써봤어요.. 예상만.. -_-)

from. TortoiseSVN의 고급기능에대해 질문이 많은 사람이..

다즐링의 이미지

제가 확인한것은 이클립스에서의 연동은 좋다 이겁니다. =)

물론 저는 그냥 브라우저를 키고 쉘에서 코딩합니다만..

검색해보니 이런 도움말이 있네요.

생각나서 찾아보니 이런것도 있네요.

------------------------------------------------------------------------------------------------
Life is in 다즐링

------------------------------------------------------------------------------------------------
Life is in 다즐링

hey의 이미지

creativeidler님과 neogeo님의 의견이 계속 돌고 도는 게 이거라고 봐요.

creativeidler님은 커밋을 자주 한다 - 로그를 반드시 읽을 필요는 없다.
neogeo님은 커밋을 적게 한다 - 로그는 반드시 써야 한다.

라고 주장을 하시는데, 전자는 둘이 상충하는 게 맞지만 후자는 안 그렇습니다. 반드시 쓰되, 반드시 읽지는 않아도 될 수도 있잖아요.

언제가 분석할 때 로그가 반드시 필요하겠지만, 매 커밋마다 로그를 읽을 필요는 없다고 봅니다.

다즐링님의 경우에는 애초에 개념도 없는 후배들 데리고 일하려니 힘들다는 예외적인 이유가 있었지만, 커밋에 드는 품이 크면 클수록 자주 안 하게 되는 것도 사실이라고 봅니다. 귀찮아서 일주일이고 한 달이고 자기 일이 끝날 때까지 커밋 안 하는 사람이 생길 수도 있는 거구요. (실제로 봤습니다.) 그래도 그 사람이 자주 업데이트를 해준다면 마지막에 한꺼번에 커밋할 때 품이 좀 덜 들겠죠. 하지만 그건 다른 사람들이 자주 커밋을 한다는 전제가 있어야 하는 것 아닙니까?

'neogeo님도 일이 끝날 때까지는 몇 주라도 커밋하지 않아도 좋다'는 극단적인 주장을 하시는 건 아니잖아요. 그렇다면 적어도 의미있는 단위로는 끊어서 커밋을 해야할텐데, 이 시간의 길이가 얼마냐, 하루에 한 번이냐 열 번이냐, 그 차이뿐이라고 보이네요.

저는 아직 20~30번 정도로 작게 의미있는 단위를 만들지는 못하는데, 할 수만 있다면 작을 수록 좋다고 봅니다. 일이 끝날 때까지라고 개인적인 기준을 잡으면 며칠이고 늘어지게 되더군요. 이건 명백히 좋지 못한 일이죠. 다들 동의하시리라 생각합니다.
----------------------------
May the F/OSS be with you..



----------------------------
May the F/OSS be with you..


다즐링의 이미지

다.. 다시 불을 붙이시는군요. -_-;;

일단 개념도 없는 후배란 말은 "잘 모른다" 와 비슷한 의미로 쓴것이라는 점을 먼저 밝혀드리구요.

그리고 저는 로그를 반드시 써야한다고 생각합니다.
물론 예외적인 상황도 있겠지만 말이죠.

협업이란 말의 의미를 여러가지로 해석이 가능하겠지만 SVN 을 협업의 도구로 쓴다면 자신이 무엇을 했는지 정도는 남겨야한다고 생각합니다.

그리고 제가 이 글을 쓴 이유는 이슈트래킹과 연계된 ( 트랙을 써보셨을 테니 ) 경우입니다.
커밋로그가 timeline 에 통합되고 이슈들이 닫기는 그러한 상황을 이야기 드리는 겁니다.
하나의 툴로 강제하는것은 좋치는 않은 일입니다만 가급적 적은 공수로 ( 모두의 합은 더 클 수도 있겠습니다만 )
많은 일을 하는 것도 의미는 있는 일이라고 생각합니다.
예를 들어 이번주에 무엇을 했는지 보고하라고 하면 타임라인만 적절히 수정해서 출력해도 괜찬은 형태의 보고가 될 수 있다고 생각합니다.

그리고 사실 프레임 혹은 말다툼이 되는 이유를 잘 모르겠습니다. 절대적인 것은 없다는 것을 다 아실텐데 말입니다.
상황따라 다른법이죠. 그때그때 다 다른 =)

------------------------------------------------------------------------------------------------
Life is in 다즐링

------------------------------------------------------------------------------------------------
Life is in 다즐링

hey의 이미지

그 그러게요.. 제가 오랜만에 오다보니 오래된 글타랜지 미처 몰랐습니다.
다즐링님의 상황에 대해서는 잘 이해했고요, 하신 말씀도 완전히 동감합니다.
----------------------------
May the F/OSS be with you..



----------------------------
May the F/OSS be with you..


free1002의 이미지

라고 쓰면 또 괜히 식은 화산에 기름붓는거 아닐까 고민되지만.. -_-; 한번의 커밋이 좀 더 가벼울 수 있는 프로젝트가 있고 그렇지 못한 프로젝트가 있을 듯 합니다.

예를 들어 저희 회사의 경우 이미 고객이 사용중인 솔루션이 브랜치가 갈리고 브랜치들이 각각 계속 버그 픽스들이 진행되고 있습니다. 이미 고객이 서비스를 운용중인 솔루션인지라 중간에 변경 자체가 발생하는 것에 대해 고민하게 됩니다. (즉, 이미 고객에게 나간 브랜치 버전은 코드 개선을 위한 지속적인 리팩토링을 진행하는 것이 위험합니다. 향후 새 릴리즈를 위한 trunk 의 코드라면 모를까..)

그러한, 유지보수 단계에 진행중인 솔루션의 경우 한번 커밋 단위에 느껴지는 무게가 좀 큽니다. 그래서 커밋 한번 당 Trac 에의 Ticket 하나를 처리할 단위만큼의 코드가 커밋되고, 이는 보통 3 man-day, 길게는 1 man-month 를 소모합니다. 커밋 전에는 전체 테스트를 돌리고 팀 리뷰를 거친 뒤에 진행됩니다. 커밋 시에는 관련 버그 번호를 적고요. 이건 자체 이슈 트래커와 연동되고 있습니다.

반면 신규 프로젝트라면 좀 더 빠른 팀원간 정보 공유를 위해서 더 가볍고 신속한 방법을 취할 수 있으리라 생각합니다. 그때에는 저러한 '변경 자체가 가지는 잠재적인 리스크' 보다는 '정보 공유를 통한 신속한 프로덕트의 진화' 로 얻는 이득이 더 클 것이고요.

다즐링의 이미지

그런것도 있겠지만

제가 두분의 처지에 있다면 다음과 같이 할꺼 같군요.

자신이 공격적인 커밋과 자주 커밋을 한다면 svk 를 써야할꺼 같고 ( 분산형으로 로컬에 커밋하고 svn 에 다시 부어버리는 형식입니다 )

neogeo 님 스타일이면 뭐든 상관은 없겠지만 ( 회사에서 필요로 한다면 ) 코드 리뷰를 진행하고 반영되는 그런 scm 을 써야할듯 하네요. =)

역시 그냥 의견입니다.

------------------------------------------------------------------------------------------------
Life is in 다즐링

------------------------------------------------------------------------------------------------
Life is in 다즐링

tinywolf의 이미지

저는 그냥 자연스럽게 합니다.
위에도 있었던 경우처럼 어차피 얼굴 보면서 하는 처지라..

그냥 말로 전달하고.
고쳐서 커밋할 때는 몇번 몇번 고쳤다 정도의 번호만 적게 하구요.

하루에 한두번 커밋하는 사람도 있고 하루에 십수번 커밋하는 사람도 있고 하지만
서로간의 충돌은 거의 없습니다.

워낙에 개성들이 뚜렷한 사람들이니..
그냥 서로 편하자고 사용하는 것이니까 편하게 쓰도록 내버려둡니다.

아마도 프로젝트 하나에 5~6명 정도로 규모가 작아서 그렇겠지요.

진짜 수십명이 여기저기 뜯어 고치는 상황이라면 어느정도 규칙이 있긴 있어야 할 것같습니다.

ㅡ_ㅡ;

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.