오픈 소스 프로젝트 - zbXE 개발 포럼
글수 237
모듈 만들다가 잠수중인 bnu입니다. 후덜덜
개발자에게만 해당되는 이야기입니다만...
trac에서 티켓을 할당받아 커밋할 때 커밋로그에 해당 티켓번호를 명시하고, 티켓에는 커밋내역으로 리비전 번호만 남겨놔도
어떤 것 때문에 수정되었는지 어떻게 고쳐졌는지 추적이 편리할 것같습니다.
텍스트큐브가 현재 위와 같이 진행중이더군요.
trac.. 잘 만들었더군요. 리비전 번호나 티켓번호 링크에 마우스 커서 올리면 풍선도움말로 커밋로그나 티켓 제목을 표시해주더군요.
텍스트큐브에서는 티켓번호를 기록하지 않은 커밋은 그냥 돌려버리는 것같더군요.
번역이나 간단한 코드수정은 허용하더라도 티켓과 연관된 커밋은 기록의 필요성이 있지 않나 싶습니다.
커밋과 티켓의 연관성을 지어줄 수 있는 장점이 있다고 봅니다.
기록의 귀찮음(?)은 단점이라고 볼 수 있을런지 모르겠습니다만^^;
한가지 더...
마일스톤별로 브랜치를 생성하는게 어떨까 싶습니다.
현재는 sandbox에서 전체 코드를 고치는데, 현재 2.0마일스톤 코드를 고친다하면 2.0 릴리즈 이전의 코드도 전반적으로 수정되어버립니다.
일반적인 코드수정은 sandbox에서 작업한다해도 큰 변경이 일어나는 코드에 대해서는 브랜치에서 수정 후 병합하는 방향이 좋겠지요.
개발자에게만 해당되는 이야기입니다만...
trac에서 티켓을 할당받아 커밋할 때 커밋로그에 해당 티켓번호를 명시하고, 티켓에는 커밋내역으로 리비전 번호만 남겨놔도
어떤 것 때문에 수정되었는지 어떻게 고쳐졌는지 추적이 편리할 것같습니다.
텍스트큐브가 현재 위와 같이 진행중이더군요.
trac.. 잘 만들었더군요. 리비전 번호나 티켓번호 링크에 마우스 커서 올리면 풍선도움말로 커밋로그나 티켓 제목을 표시해주더군요.
텍스트큐브에서는 티켓번호를 기록하지 않은 커밋은 그냥 돌려버리는 것같더군요.
번역이나 간단한 코드수정은 허용하더라도 티켓과 연관된 커밋은 기록의 필요성이 있지 않나 싶습니다.
커밋과 티켓의 연관성을 지어줄 수 있는 장점이 있다고 봅니다.
기록의 귀찮음(?)은 단점이라고 볼 수 있을런지 모르겠습니다만^^;
한가지 더...
마일스톤별로 브랜치를 생성하는게 어떨까 싶습니다.
현재는 sandbox에서 전체 코드를 고치는데, 현재 2.0마일스톤 코드를 고친다하면 2.0 릴리즈 이전의 코드도 전반적으로 수정되어버립니다.
일반적인 코드수정은 sandbox에서 작업한다해도 큰 변경이 일어나는 코드에 대해서는 브랜치에서 수정 후 병합하는 방향이 좋겠지요.






매우 편하더군요.
그리고 브랜치의 경우 다 같이 논의가 필요하지 않을까 싶습니다.
머지(merge) 비용이 꽤나 커서 어떻게 하면 효율적으로 할지에 대한 이야기가 필요할거 같아요.