저는 svn이 CVS의 모든 부분에서 개선되었지만 branch/tag만은 더 낫다고 얘기하지 못하겠습니다. 표현력으로만 보면 분명히 branch/tag 기능을 copy를 통해서 할 수 있도록 하고 있지만, 일반화를 위해서 간단한 개념을 너무 더 복잡하게 만든 아닌가 생각이 듭니다.
branch/tag를 만드는 데 /branches/blahblah, /tags/blahblah 라고 엔드유저가 정책을 스스로 결정해서 집어 넣어야 된다는 게 별로 직관적이지는 않습니다. 예를 들어 "어떤 파일의 branching/tagging이 어떻게 되어 왔는지" 알아보려면 CVS보다 훨씬 복잡합니다. CVS는 branching이 뭐고 tagging이 이름만으로 나타나는데 svn은 모든 게 copy로 일반화되다보니 그 기록을 보고 정책에 따라 어떻게 뭐가 branching되고 tagging되었는지 판단해야 되기 때문입니다.
branch, tag의 개념이
branch, tag의 개념이 svn으로 오면서 없어지고(?), 그 개념을 copy라는 개념으로 승화시켰습니다.(?)
흠... 예전 회사에서 cvs로 몇년여 개발하다가 통째로 svn으로 옮겼는데... svn이 개념상, 기능상, cvs보다 더 우위라는걸 개인적으로 느꼈습니다.
cvs를 쓰시다가 svn을 첨 접하면, svnbook 함 쭉 읽어보시면 좋을 듯 합니다.. 거기에 branch, tag에 대해서 어떻게 하라고 자세히 설명이 되어있습니다.
저는 svn이 CVS의 모든
저는 svn이 CVS의 모든 부분에서 개선되었지만 branch/tag만은 더 낫다고 얘기하지 못하겠습니다. 표현력으로만 보면 분명히 branch/tag 기능을 copy를 통해서 할 수 있도록 하고 있지만, 일반화를 위해서 간단한 개념을 너무 더 복잡하게 만든 아닌가 생각이 듭니다.
branch/tag를 만드는 데 /branches/blahblah, /tags/blahblah 라고 엔드유저가 정책을 스스로 결정해서 집어 넣어야 된다는 게 별로 직관적이지는 않습니다. 예를 들어 "어떤 파일의 branching/tagging이 어떻게 되어 왔는지" 알아보려면 CVS보다 훨씬 복잡합니다. CVS는 branching이 뭐고 tagging이 이름만으로 나타나는데 svn은 모든 게 copy로 일반화되다보니 그 기록을 보고 정책에 따라 어떻게 뭐가 branching되고 tagging되었는지 판단해야 되기 때문입니다.
----
익명이나 오래전 글에 리플은 무조건 -1
댓글 달기