tag:blogger.com,1999:blog-6060875800282210631.post5045021120152019489..comments2023-11-08T05:29:09.590+09:00Comments on All of Software: 소스코드는 어디 있나요?전규현http://www.blogger.com/profile/02706025917864233238noreply@blogger.comBlogger17125tag:blogger.com,1999:blog-6060875800282210631.post-76517800517522818152010-03-29T17:55:45.000+09:002010-03-29T17:55:45.000+09:00당연한 얘기를 글로써 상기 시킨다는 현실이 참 슬프네요저도 한번은 그렇게 큰 사이트가 아닌...당연한 얘기를 글로써 상기 시킨다는 현실이 참 슬프네요<br>저도 한번은 그렇게 큰 사이트가 아닌데 소스만 400MB<br>짜리를 본적이 있었습니다. portal1,portal2,real-portal.....<br>같은 디렉토리가 여러개 있는데 마치 닭 갈비집 이름 처럼<br>"원조집","진짜원조집","진짜진짜원조집" 같은 느낌이였습니다.<br>시스템은 점점더 고도화되고 복잡한 기술을 사용하는데<br>개발 환경과 현실은 너무 구닥다리를 따르고 있습니다.Beyond J2EEhttp://beyondj2ee.blogspot.com/noreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-66258578356808673372010-03-30T13:46:36.000+09:002010-03-30T13:46:36.000+09:00Beyond J2EE님 안녕하세요.정말 적절한 비유입니다.이런 소스코드는 감당하지도 못합니...Beyond J2EE님 안녕하세요.<br><br>정말 적절한 비유입니다.<br>이런 소스코드는 감당하지도 못합니다. 소스코드관리시스템의 브랜치와 머지 기능을 충분히 활용하고 개발 프로세스 상에서 이를 잘 통제하면 부처님 손바닥안의 소스코드죠. <br><br>언제 다 같이 모아 놓고 세미나를 한번 하고 싶은 마음은 굴뚝 같은데 여유가 안생기네요. - -;Ray.전규현http://allofsoftware.netnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-79372427627593288512010-03-30T08:46:34.000+09:002010-03-30T08:46:34.000+09:00항상 좋은 글 감사합니다^^ 개발자로써 구구절절 옳은 말씀만 올려주시지만 현실과의 괴리감이...항상 좋은 글 감사합니다^^ 개발자로써 구구절절 옳은 말씀만 올려주시지만 현실과의 괴리감이 드는 건 어쩔수가 없네요. 형상관리를 하고 있지만 어느 순간에서부턴가 각 개발자끼리 마치 개별 브랜치를 가진 듯이 다른 방향으로 진행되고 있는 상황을 자주 접하게 됩니다. 물론 상황에 따라 머징이 되긴 하지만 주기적으로 이루어지는 머징도 아니고 필요에 따라, 상황에 따라 이루어지다보니 커뮤니케이션이 소홀해 지는 경우 각자의 프로젝트는 결국 다른 산으로 가고 있더군요.<br>다시 한번 좋은 글로 일깨워주심에 감사드립니다~^^옥수석noreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-8642029896088577722010-03-30T13:44:08.000+09:002010-03-30T13:44:08.000+09:00안녕하세요. 옥수석님당연한 기초가 현실과 괴리가 있는 현실이 안타깝습니다. 대학생들을 갈쳐...안녕하세요. 옥수석님<br><br>당연한 기초가 현실과 괴리가 있는 현실이 안타깝습니다. 대학생들을 갈쳐도 몇주면 익숙해지는 것을 십수년 경력의 개발자들도 제대로 하지 못하는 것이 현실이기는 하죠.<br><br>브랜치와 머지는 보통 개발자가 마음대로 하면 안됩니다. 이에 대한 회사의 정책이 있고 개발자는 이를 따라야죠. 일반적으로 브랜치는 승인하에서 합니다. 머지계획도 미리 작성해야 하고요. 번거로우라고 이렇게 하는 것이 아니고 이렇게 하는 것이 가장 효율적이기 때문입니다.<br><br>또 머지는 3-way머지를 해야 합니다. 보통 2-way머지툴을 가지고 머지를 하는데 이는 수십배 더 시간이 많이 들고 잘못 머지가 될 가능성도 대단히 높습니다.<br><br>이렇게 해 놓고 개발자들이 계획에 따라서 자유롭게 개발하는 것이 좋지, 대충 해놓고 뭔가 고칠려고 할 때마다 소스코드 공유/통합을 신경써야 한다면 프로젝트 기간 내내 소스관리 비용이 몇백배로 더 많이 들게 됩니다.<br><br>산으로 가고 있다면 다시 땅으로 끌어 내려야 겠네요. ^^ 필요하면 제가 세미나 등을 통해서 개발자와 경영진들을 설득시키고 교육도 시켜주곤 합니다.Ray.전규현http://allofsoftware.netnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-91485782026616720622010-03-31T10:06:37.000+09:002010-03-31T10:06:37.000+09:00구차니에서 날탱구리로 블로그 및 필명을 변경했답니다.음.. 개인적인 질문인데, svn에서 ...구차니에서 날탱구리로 블로그 및 필명을 변경했답니다.<br><br>음.. 개인적인 질문인데, svn에서 프로젝트를 어떻게 관리 하시나요?<br>예를 들어 리눅스 박스의 경우 uboot / linux kernel / 자체 sw 가 있는데<br>세가지를 svn repository 하나에 넣으면 revision이 같이 올라가게 되고,<br>그렇다고 해서 분리를 해서 개별 리파지터리를 만들면 개별 주소를 기억을 하거나<br>별도로 관리하는 방법이 필요할 것 같더라구요.날탱구리http://nall.tistory.comnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-10944481814526902322010-03-31T14:29:57.000+09:002010-03-31T14:29:57.000+09:00Repository를 어떻게 나누고 각 Repository안의 프로젝트 별 디렉터리를 어떻...Repository를 어떻게 나누고 각 Repository안의 프로젝트 별 디렉터리를 어떻게 구성하는지는 회사마다 다릅니다.<br>일단 revision number는 신경쓰지 않는 것이 좋습니다. revision number에 의미를 부여해서 사용하면 나중에 문제가 발생합니다.<br>Repository구분은 각 프로젝트가 단 0.1%라도 서로 연관성이 있는지를 봐야 합니다. 공유되는 소스코드가 있는지? 나중에 쓰고 버릴 소스코드인지? 백업은 공통으로 해야 하는지? 이렇게 생각을 해보고 연관이 있으면 한 Repository에 넣는 것이 좋습니다.<br>Repository안의 디렉터리 구조는 각 프로젝트가 완전히 자동으로 Build가 가능하도록 구성을 해야 하는데 공통모듈이 잘 관리되고 있는 회사가 아니라면 이 말이 무슨 뜻인지 잘 모를겁니다. 하지만 공통모듈이 있다면 디렉터리를 어떻게 구성하냐에 따라서 빌드가 달라집니다.<br><br>이렇게 여러가지를 고려하여 처음부터 잘 정해 놓고 시작해야지 나중에 바꾸려고 하면 큰 문제입니다. <br><br>리파지터리 주소는 프로젝트 check out할 때 처음에 한번만 입력하면 되는 것이기 때문에 기억하는 것은 문제가 알될 것 같습니다.Ray.전규현http://allofsoftware.netnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-40842305129069963862010-03-31T10:51:26.000+09:002010-03-31T10:51:26.000+09:00늘 잘 안되는 것들이 포스팅이 되어서 마음이 아팠었는데오늘 포스팅에 대해서는 자신감이 생기...늘 잘 안되는 것들이 포스팅이 되어서 마음이 아팠었는데<br><br>오늘 포스팅에 대해서는 자신감이 생기네요..<br>svn을 사용하고 있고 capistrano를 통해서 각 환경(개발, 백업, 리얼)으로 소스를 deploy 할수 있고 이슈트래킹의 부가기능에 svn history를 연결해놔서 누가 언제 어떻게 고쳤는지 웹상으로 확인할수 있습니다. ^^ 이정도면 자신감을 가져도 괜찮겠죠?zeoushttp://zeous.egloos.comnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-47972371679329119182010-03-31T14:32:57.000+09:002010-03-31T14:32:57.000+09:00안녕하세요. zeous님일단 SVN과 이슈트래킹(아마 Trac)을 연동해서 잘 쓰고 계시나...안녕하세요. zeous님<br>일단 SVN과 이슈트래킹(아마 Trac)을 연동해서 잘 쓰고 계시나보네요. 평균 이상은 되시네요. ^^<br>항상 안되는 것만 있으면 빵점이게요? 그럴리가 있겠습니까? 항상 포스트를 보면서 조금씩 고쳐나가자는 의미입니다.<br>SVN을 잘 쓰시는 것 같기는 한데 Branch, Merge는 어떻게 하는지 궁금하네요. 사실 SVN의 핵심은 Merge거든요. 나중에 Git나 Mercurial들의 분산소스코드관리시스템을 쓰더라도 Merge를 제대로 하지 못하면 반쪽짜리가 됩니다. 그래서 3-Way Merge를 능수능란하게 다룰 수 있어야 합니다. 어떠신가요?Ray.전규현http://allofsoftware.netnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-988122497995281282010-03-31T19:13:23.000+09:002010-03-31T19:13:23.000+09:00branch를 전혀 쓰지 않는 것은 아닙니다.이번에도 새로운 프로젝트를 시작하는데 기존 소...branch를 전혀 쓰지 않는 것은 아닙니다.<br>이번에도 새로운 프로젝트를 시작하는데 기존 소스의 서비스도 유지하면서 거기에서 파생되어서 추가적인 작업을 하고 완성후에 합치기 위해서 branch를 생성해서 작업을 하고 있습니다만은<br><br>branch를 생성하고 나서 마지막에 합칠때 실수하지 않을까 (자동으로 하게 되면 가끔 한쪽을 날려먹는 경우가 있어서 안볼수는 없더라구요)<br>챙겨야 할것들이 있기에 이왕이면 안만들어졌으면 하는 바램은 있습니다 ^^zeoushttp://zeous.egloos.comnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-70069912328712262752010-04-02T20:11:03.000+09:002010-04-02T20:11:03.000+09:00SVN을 쓰는 곳, 다수가 해당 소스를 Root에 그냥 올려버리는 곳을 많이 봤습니다.Br...SVN을 쓰는 곳, 다수가 해당 소스를 Root에 그냥 올려버리는 곳을 많이 봤습니다.<br>Branch나 Tags, Merge와 같은 기능은 꺼버리고 사용하는 것과 마찬가지 인데도 불구하고 말입니다.<br>초반엔 인식을 심어주려고 교육도 해보고 노력했으나..역시나 이쪽 부분엔 관심 없어 하더군요.<br><br>무술고수가 항상 강조하는 기본기 "정권찌르기"를 거스르고 현란한 기술만 쓰고자 하는 사람들의 심리때문일까요? 아니면 남들이 모르니 나도 몰라도 된다..라는 심리때문일까요<br><br>가장 기본이 되는 소스코드 관리 정말 중요하죠~ 말이 필요없다고 생각합니다. <br>하나를 보면 열을 안다고.. 이런 기본을 중요시하는 기본기가 탄탄한 조직은 정말 안정적인 조직이라고 생각합니다. ( 비단 소스코드관리뿐만이 아닌...:)moovahttp://moova.tistory.comnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-35217972711000792622010-04-10T01:12:04.000+09:002010-04-10T01:12:04.000+09:00moova님 안녕하세요.제가 좀 바빴네요. - -;소스코드시스템을 쓰는 이유가 소스코드를 ...moova님 안녕하세요.<br>제가 좀 바빴네요. - -;<br>소스코드시스템을 쓰는 이유가 소스코드를 잃어버릴까봐 백업용도로만 쓰는 곳이 의외로 많습니다.<br>빠뀌지 않는 이유는<br>1. 막연히 새로운 것을 배우는 것이 귀찮아서<br>2. 나아진 다는 확신이 없어서<br>3. 현재 방법에 익숙해져서<br>4. 가르쳐 주는 사람에 대한 믿음이 부족해서<br>5. 소스코드를 감추려고<br>등등 다양합니다.<br>산넘어 산입니다.<br>그래서 카리스마 있는 사람의 도움을 받아서 설득을 하면서 강제화하는 것이 가장 좋은 방법입니다.Ray.전규현http://allofsoftware.netnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-63621856332434832462010-04-20T15:03:36.000+09:002010-04-20T15:03:36.000+09:00어느분이 지적하신대로 저 역시 Branch, Tags, Merge 기능을 사용해보질 못했네...어느분이 지적하신대로 저 역시 Branch, Tags, Merge 기능을 사용해보질 못했네요 -_-;tackhttp://tack.tistory.comnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-74968341432119403662010-04-20T15:23:22.000+09:002010-04-20T15:23:22.000+09:00현재 SVN의 기본 저장 기능만 쓰고 계신거라고 볼 수 있습니다. 혼자서 개발을 해도 브랜...현재 SVN의 기본 저장 기능만 쓰고 계신거라고 볼 수 있습니다. 혼자서 개발을 해도 브랜치 요구는 항상 생깁니다.Ray.전규현http://allofsoftware.netnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-13981752887503852982010-04-11T07:17:09.000+09:002010-04-11T07:17:09.000+09:00소스코드는 어디 있나요? 에서 트랙백 합니다. Development Team Buildin...소스코드는 어디 있나요? 에서 트랙백 합니다. Development Team Building Consulting, 거창해 보이지만 그냥 IT 관련 개발 인력들로 부서를 만들어야 하거나 어떻게든 제대로된 유지보수 부서를 꾸려야 하는 곳에 도움을 주는 일입니다. 원문의 내용에 심히 공감하게 됩니다. 1년 반동안 다섯 Team을 컨설팅을 했었고, 두 Team은 내부적인 사정으로 포기를 했고 두 Team은 나름의 결과를 내서 회사 운영 System과 잘 ...Blog.RedAge.NEThttp://blog.redage.net/254noreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-86635808122600531202010-04-12T00:28:26.000+09:002010-04-12T00:28:26.000+09:00소스코드는 어디 있나요? http://bit.ly/ao8197소스코드는 어디 있나요? http://bit.ly/ao8197murian's me2DAYhttp://me2day.net/murian/2010/03/29#15:47:41noreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-56689880553474099012010-04-13T12:25:24.000+09:002010-04-13T12:25:24.000+09:00소스코드는 어디 있나요?. SCM 에 저장된 소스를 one-click build 는 꼭 필...소스코드는 어디 있나요?. SCM 에 저장된 소스를 one-click build 는 꼭 필요하다에 한 표. 이왕이면 CI 에 daily build 의 결과물까지 web 에 바로 올라가고, 누구든 손쉽게 download 해볼 수 있으면 더 좋구… CI 에 더 나가서tkhwang's me2DAYhttp://me2day.net/tkhwang/2010/03/29#18:29:00noreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-53922896668511246822010-04-22T01:56:47.000+09:002010-04-22T01:56:47.000+09:00서브버전을 이용한 실용적인 버전 관리 저자 Mike Mason 역자 류광 출판사 정보문화사...서브버전을 이용한 실용적인 버전 관리 저자 Mike Mason 역자 류광 출판사 정보문화사 오픈 소스 버전 관리 시스템인 서브버전(Subversion)의 효과적인 활용을 담고 있는『서브버전을 이용한 실용적인 버전 관리』. 이 책에서는 버전 관리 시스템을 최대한 활용하기 위한 여러 기본적인 조리 법들을 제시하고 있다. 《서브버전을 이용한 실용적인 버전 .. 버전 관리가 뭔지도 모르던 그 때 그 시절에는 그저 파일에 숫자나, 연월일을 붙여가며 해당 파일..RayGhttp://rayg.tistory.com/21noreply@blogger.com