기반시스템/소스코드관리 썸네일형 리스트형 하루에 몇 번 커밋하세요? 한 개발자가 하루에서 수도 없이 커밋(Commit)을 하고 있다면 소스코드관리시스템을 백업서버로 쓰고 있을 가능성이 높습니다. 사실 이러한 경우를 매우 자주 봤습니다. 혹시 코딩을 하다가 점심 먹으러 간다고 한번 커밋하고 중간 중간에 수시로 커밋을 하고 있으면 이건 좋은 방법은 아닙니다. 혹시 이런 방법으로 소스코드관리시스템(SVN, CVS, VSS, ClearCase 등)을 사용하고 계신지 확인해보십시오. 본인이 아니라도 이렇게 백업용도로 사용하고 있는 동료나 후배가 없는지 확인해보십시오. 커밋을 하면 소스코드의 Revision이 바뀌게 되는데, 각각의 Revision은 의미를 가지게 됩니다. 그 의미가 "점심 먹으러 나가면서 임시로 저장" 이렇게 되면 곤란합니다. 각 Revision의 정보는 우리회사.. 더보기 Diff and Merge in SCM(Software Configuration Management) 헝그리맨님의 Subversion(TortoiseSVN)의 Diff에서 한글이 깨지는 문제... 에 관한 포스팅에 대하여 답변 겸 SCM에서의 Diff와 Merge에 대해서 글을 남겨 봅니다. 일단 헝그리맨님의 글에 대한 답변을 먼저 해야 겠군요. 사실 그동안 소스코드를 Diff하고 Merge하는데는 GUI Diff, Merge툴의 한글 깨지는 문제는 크게 신경을 쓰지 않았습니다. 대부분의 소스코드는 거의 영어로 되어 있고, 주석에 일부 한글이 들어 갔어도 이부분이 수정되서 Diff, Merge가 필요한 부분이 거의 없었고, 대부분의 머지는 줄단위로 이루어져서 줄 내에서 한글을 깨지게 표현하는 것은 사실 문제가 안되었습니다. 3-way merge를 할때는 오랫동안 Unified diff를 사용했기 때문에 .. 더보기 Release Branch, Function Branch and Customer Branch 서영아빠님의 "브랜치를 이용하여 운영환경에 선별적으로 배포하기"란 글을 보고 소프트웨어 프로젝트에서 브랜치란 어떤 의미를 가지는지 "소프트웨어 개발의 모든것"이라는 책에서 이에 대하여 소개한 내용이 있는데 이를 인용하여 설명을 하려고 합니다. 여기서 소개하는 브랜치에 대한 얘기의 핵심은 브랜치의 위험성에 대한 "경고"입니다. 브랜치는 위험하지만 소프트웨어 개발에서는 흔히 꼭 필요하게 되어서 철저히 통제가 되어야 한다는 것입니다. 브랜치(Branch) 브랜치란 필요에 의해서 소스코드를 분기하는 것이다. 브랜치를 얼마나 잘 통제하는가가 훌륭한 소프트웨어 회사와 평범한 소프트웨어 회사를 구별하는 핵심 요소 중 하나이다. 브랜치를 해야 하는 경우를 예로 들면 다음과 같다. 제품을 출시 후 유지보수를 하면서 동시.. 더보기 Subversion(SVN)과 CVS의 비교 Subversion(SVN)과 CVS에 대한 비교라기 보다는 SVN이 CVS와 비교하여 상대적으로 어떤 점이 더 좋은지에 대한 설명입니다. SVN은 CVS를 개발하던 핵심 개발자들이 그동안 CVS가 가지고 있던 문제를 해결하고자 완전히 새로운 아키텍쳐로 새로 만든 제품입니다. 따라서 기존에 CVS를 사용하고 있던 개발자들은 SVN으로 넘어오는 것을 적극 검토해보시기 바랍니다. Subversion(SVN)의 장점 CVS에 비해 엄청나게 빠른 업데이트/브랜칭/태깅 시간. -> 최고로 강력한 장점입니다. 기존에 대형 프로젝트 같은 경우는 CVS를 이용하면 태깅에 수십분이 걸리기도 했습니다. 하지만 SVN은 아무리 규모가 커도 몇초면 끝납니다. 커밋 단위가 파일이 아니라 체인지셋이라는 점입니다. CVS에서라면 .. 더보기 소스코드관리시스템을 몇개 사용하고 있나요? 소프트웨어 개발 컨설팅을 하다보면 여러가지 경우를 보지만 그중의 한 예를 소개할까 합니다. 국내의 굴지의 금융회사 중의 한 사례입니다. 회사 내에서 각 팀별로 소스코드관리시스템을 여러 개를 사용하고 있더군요. A팀 Windows 플랫폼의 Application를 개발하니까 Microsoft Visual SourceSafe를 사용하고 B팀 Web 서비스를 개발하고 있었는데, CVS를 사용하더군요. 그리고 C팀은 Unix에서 개발을 하는데, 아무런 소스코드관리시스템을 사용하고 있지 않았고, D팀은 별로 잘 알려져 있지 않은 외국의 상용 제품의 한글화된 버전을 사용하고 있었습니다. 한 회사에 총 4가지 유 형의 소스코드 관리가 존재하는 겁니다. 이런 상황에서는 다음과 같은 부작용이 생깁니다. 개발자들이 다른 부.. 더보기 이전 1 2 3 다음
