예전글에서 프로젝트 리비전을 분할관리 해야할 것 같아서 다시 한번 시도를 해봤는데 아래와 같은 내용이 있었다.

USAGE:
cvs2svn [OPTIONS]... [-s SVN-REPOS-PATH|--dumpfile=PATH|--dry-run] CVS-REPOS-PATH
cvs2svn [OPTIONS]... --options=PATH
CVS-REPOS-PATH The filesystem path of the part of the CVS repository that you want to convert. It is not possible to convert a CVS repository to which you only have remote access; see the FAQ for details. This doesn't have to be the top level directory of a CVS repository; it can point at a project within a repository, in which case only that project will be converted. This path or one of its parent directories has to contain a subdirectory called CVSROOT (though the CVSROOT directory can be empty).
Configuration via options file
--options=PATH Read the conversion options from the specified file. See section options file method for more information.
Output options
-s PATH
--svnrepos PATH
Write the output of the conversion into a Subversion repository located at PATH. This option causes a new Subversion repository to be created at PATH unless the --existing-svnrepos option is also used.

[링크 : http://cvs2svn.tigris.org/cvs2svn.html]



예를들어
/home/cvs
|-- CVSROOT
|-- Project1
|-- Project2
`-- Project3
이런구조의 cvs repository라면,

$ cvs2svn --svnrepos /home/svn/ --encoding=cp949 /home/cvs/
으로 할경우, 리비전이 전부 하나로 묶이고, 프로젝트가 분리되지 않는다.

$ cvs2svn --svnrepos /home/svn/Project1 --encoding=cp949 /home/cvs/Project1
$ cvs2svn --svnrepos /home/svn/Project2 --encoding=cp949 /home/cvs/Project2
$ cvs2svn --svnrepos /home/svn/Project3 --encoding=cp949 /home/cvs/Project3
이렇게 하면 개별 프로젝트로 repository가 생성이 된다.
(부가적으로 revision이 단순해져서 변환도 상대적으로 빨라지는 듯하다)

2009/05/10 - [프로그램 사용/CVS / SVN / GIT] - cvs2svn 사용방법

'프로그램 사용 > Version Control' 카테고리의 다른 글

visualSVN  (0) 2010.09.09
TortoiseSVN tag/branch = copy  (2) 2010.04.30
svn / svnadmin 도움말  (0) 2010.04.23
CVS / SVN 장단점, 차이점 비교  (6) 2010.04.07
GIT는 리눅스에서 받으시는걸 추천합니다.  (0) 2010.03.18
Posted by 구차니
자세히 보면 티가 나지만, 어떤녀석은 URL 이고 어떤 녀석은 PATH이다.
일단 URL에서 파일 경로일 경우에는 file:/// 이라고 / 개 3개가 들어가야 한다.

$ svnadmin create [repository direcotry name]
$ svn checkout file:///[absolute path] [name of repository which will create]

머.. 일단 콘솔에서는 이렇게 초기화 하고 만들면 될 듯.

$ svnadmin help
general usage: svnadmin SUBCOMMAND REPOS_PATH  [ARGS & OPTIONS ...]
Type 'svnadmin help <subcommand>' for help on a specific subcommand.

Available subcommands:
   crashtest
   create
   deltify
   dump
   help (?, h)
   hotcopy
   list-dblogs
   list-unused-dblogs
   load
   lslocks
   lstxns
   recover
   rmlocks
   rmtxns
   setlog
   verify

$ svnadmin help create
create: usage: svnadmin create REPOS_PATH

Create a new, empty repository at REPOS_PATH.

Valid options:
  --bdb-txn-nosync         : disable fsync at transaction commit [Berkeley DB]
  --bdb-log-keep           : disable automatic log file removal [Berkeley DB]
  --config-dir arg         : read user configuration files from directory ARG
  --fs-type arg            : type of repository: 'fsfs' (default) or 'bdb'

$ svn help
usage: svn <subcommand> [options] [args]
Subversion command-line client, version 1.3.2.
Type 'svn help <subcommand>' for help on a specific subcommand.

Most subcommands take file and/or directory arguments, recursing
on the directories.  If no arguments are supplied to such a
command, it recurses on the current directory (inclusive) by default.

Available subcommands:
   add
   blame (praise, annotate, ann)
   cat
   checkout (co)
   cleanup
   commit (ci)
   copy (cp)
   delete (del, remove, rm)
   diff (di)
   export
   help (?, h)
   import
   info
   list (ls)
   lock
   log
   merge
   mkdir
   move (mv, rename, ren)
   propdel (pdel, pd)
   propedit (pedit, pe)
   propget (pget, pg)
   proplist (plist, pl)
   propset (pset, ps)
   resolved
   revert
   status (stat, st)
   switch (sw)
   unlock
   update (up)

Subversion is a tool for version control.
For additional information, see http://subversion.tigris.org/

$ svn help list
list (ls): List directory entries in the repository.
usage: list [TARGET[@REV]...]

  List each TARGET file and the contents of each TARGET directory as
  they exist in the repository.  If TARGET is a working copy path, the
  corresponding repository URL will be used. If specified, REV determines
  in which revision the target is first looked up.

  The default TARGET is '.', meaning the repository URL of the current
  working directory.

  With --verbose, the following fields will be shown for each item:

    Revision number of the last commit
    Author of the last commit
    If locked, the letter 'O'.  (Use 'svn info URL' to see details)
    Size (in bytes)
    Date and time of the last commit

Valid options:
  -r [--revision] arg      : ARG (some commands also take ARG1:ARG2 range)
                             A revision argument can be one of:
                                NUMBER       revision number
                                "{" DATE "}" revision at start of the date
                                "HEAD"       latest in repository
                                "BASE"       base rev of item's working copy
                                "COMMITTED"  last commit at or before BASE
                                "PREV"       revision just before COMMITTED
  -v [--verbose]           : print extra information
  -R [--recursive]         : descend recursively
  --incremental            : give output suitable for concatenation
  --xml                    : output in XML
  --username arg           : specify a username ARG
  --password arg           : specify a password ARG
  --no-auth-cache          : do not cache authentication tokens
  --non-interactive        : do no interactive prompting
  --config-dir arg         : read user configuration files from directory ARG

$ svn help checkout
checkout (co): Check out a working copy from a repository.
usage: checkout URL[@REV]... [PATH]

  If specified, REV determines in which revision the URL is first
  looked up.

  If PATH is omitted, the basename of the URL will be used as
  the destination. If multiple URLs are given each will be checked
  out into a sub-directory of PATH, with the name of the sub-directory
  being the basename of the URL.

Valid options:
  -r [--revision] arg      : ARG (some commands also take ARG1:ARG2 range)
                             A revision argument can be one of:
                                NUMBER       revision number
                                "{" DATE "}" revision at start of the date
                                "HEAD"       latest in repository
                                "BASE"       base rev of item's working copy
                                "COMMITTED"  last commit at or before BASE
                                "PREV"       revision just before COMMITTED
  -q [--quiet]             : print as little as possible
  -N [--non-recursive]     : operate on single directory only
  --username arg           : specify a username ARG
  --password arg           : specify a password ARG
  --no-auth-cache          : do not cache authentication tokens
  --non-interactive        : do no interactive prompting
  --config-dir arg         : read user configuration files from directory ARG
  --ignore-externals       : ignore externals definitions


'프로그램 사용 > Version Control' 카테고리의 다른 글

TortoiseSVN tag/branch = copy  (2) 2010.04.30
cvs2svn 사용방법 2  (0) 2010.04.23
CVS / SVN 장단점, 차이점 비교  (6) 2010.04.07
GIT는 리눅스에서 받으시는걸 추천합니다.  (0) 2010.03.18
TortoiseGIT  (0) 2010.03.18
Posted by 구차니
cvs와 svn을 사용하면서 느끼는 점은, 우열을 가리긴 모호하다는 것이다.
cvs가 나은점도 있고, svn이 나은점도 있고,
이러한 모호함 때문에 일단 회사 개발소스는 cvs로 유지중이긴 하지만...


거두절미하고, svn은 cvs의 단점을 개선하기 위해 만들어진건데
가장 큰 변경사항은 svn에서 디렉토리 이동이 편해졌다는 점이다.
cvs은 특정 소스의 위치를 변경하거나, 하위 디렉토리의 위치를 변경하기 위해서는
소스를 새로운 곳에 새롭게 Add 하고 기존의 파일을 Delete 해야 해서
이력추적을 할 수 없게 되지만, svn에서는 이력추적이 가능해진다.


일단 사소한 것들을 고고싱 (기준은 CVS)

SVN의 장점

1. 디렉토리 이동이 편리함
    안정화된 프로젝트라면 상관없지만, 프로젝트 초기에는 디렉토리 이동이나 파일 삭제/이름 변경이 빈번한데
    cvs는 이러한 이력을 남길수가 없기 때문에, 초기 프로젝트 셋업시에는 svn이 매우 편리함.
    (이동도 편리하지만, 그에 비해 이력이 따라와서 과거의 변경점이 유지 된다는 부가적인 장점)

2. 오프라인 사용이 용이함
    확실하게 어느정도까지 오프라인 사용이 가능한지는 모호하지만, 최소한 마지막 버전과 Diff가 가능하다.
    cvs에서는 항상 서버와 비교를 하기 때문에 소스 변경사항이 있는건 알아도
    어떤 내용이 서버와 차이가 있는지 알수 없지만, svn 에서는 오프라인에서도 diff가 가능함
    (svn 자체적으로 데이터를 유지하고 있음 = 받는 측 용량 부담 증가)

3. 서버 하드공간이 절약
    cvs을 cvs2svn으로 변환해본 결과 대략 25% 이상의 공간이 절약됨
    초기 업로드는 원본으로 올리지만, diff 내용들을 gzip으로 압축하므로 서버 공간 요구량이 줄어듦
    2009/05/11 - SVN과 CVS 저장소 용량비교(compare Repository Size of CVS & SVN)

4. 커밋마다 revision이 올라감
    하나의 변동사항이나, 복수의 파일을 한번에 commit 하면 revision이 변동되고,
    프로젝트 전반적인 변동사항을 추적하기 편리함.
    cvs는 파일단위 revision이기 때문에 프로젝트 전체의 변동이나
    "어떤 파일이 변경되기 이전 시점"으로 롤백하기 매우 난해하나
    svn에서는 commit 단위로 revision이 붙으므로, 잘못 commit 하더라도 복구가 용이함
    (부가적으로 cvs에 비해서 프로젝트 전반적인 변경의 흐름을 읽기 쉬움)

5. atomic commit
    atomic 은 DB에서 하나의 행동의 묶음이 완결되지 않으면 수행되지 않은것으로 복구가 되는 것을 의미하는데
    cvs에서 아무생각없이 commit에서 변동사항들을 본다고 하다가 commit 눌러 올려서 도중에 cancel 했지만
    몇개는 변경되어 난감한 상황을 겪어봤다면 이 녀석의 유용함을 깨달을 수 있다.



SVN 단점

1. 서버 구성이 괴랄하다
    무슨 svn 제대로 쓰려면 apache까지 깔아야 해?
    로그를 남기기 위해서는 svn 자체적으로는 로그가 안남으므로 apache의 로그나 인증을 이용해야 함.
    관리자 측면에서 로그가 남지않는다는건.. 좀 불안해진다.
    (머...... 사용자는 서버 관리자의 고충은 알바없지?)

2. tag 관리가 밋밋함
   너무 많은 자유는 없는것과 다름 없다지만.. svn의 표준(?) repository는 아래와 같이 구성한다.
   2009/05/11 - SVN repository 구조

   개별 프로젝트 별로 trunk / branches / tag를 관리하고
   tagging을 위해서 전체 프로젝트를 tag 하위 디렉토리로 tag 번호를 붙여 복사해주면 된다.
   어쩌면 매우 간편하지만, cvs의 정말 꼬리표를 붙인다는 작업에 비하면 아쉬운 면이 있다.
   cvs에서는 tagging을 하려면 서버와 local의 내용이 동일해야 하고, tagging시 변동 파일이 하나라도 있으면 붙일수 없어
   업데이트 되지 않는 파일이 있는지 빼먹지 않을수 있는 여지가 있지만, svn은 서버에서 클라이언트를 보지 않고
   작업이 가능해지므로 업데이트 되지 않은(혹은 누구가 그 순간 올린 내용까지) 부분이 빼먹거나 더 들어갈수 있다.
   개인 취향이겠지만, tag는 cvs의 약간은 딱딱하고 붙이는 맛이 있는 것이 좋다고 생각한다.

3. repository 구성의 모호함
   repository는 위와 같이 구성하려면 svn 사용자는 /calc /paint 두개의 repository를 기억해야 한다.
   commit 별로 revision이 증가하는 장점의 역효과로서, 단일 프로젝트레 단일 repository를 보장해주어야 제 힘을 발휘한다.
   서로 연관이 있는 두개의 프로젝트라고 하더라도 되도록이면 프로젝트를 분리하는 것이 좋다.
   (현재까진 상위 디렉토리의 목록을 (= 프로젝트 목록) 얻어내는 법을 모르겠다.)

   /home/svn을 만들고
   /home/svn/calc 에 create repository
   /home/svn/paint 에 create repository 를 하고
   svn에서는 /home/svn/calc , /home/svn/paint가 있음을 외우고 써야한다.
   (/home/svn에 접속하면 리파지터리를 알 수 없으므로 에러가 발생한다.)


'프로그램 사용 > Version Control' 카테고리의 다른 글

cvs2svn 사용방법 2  (0) 2010.04.23
svn / svnadmin 도움말  (0) 2010.04.23
GIT는 리눅스에서 받으시는걸 추천합니다.  (0) 2010.03.18
TortoiseGIT  (0) 2010.03.18
SVN repository 어떻게 구성하지?  (2) 2010.03.08
Posted by 구차니
아직 msysgit는 cygwin을 기반으로 해서
native win32API를 사용하지 못해 다운로드 속도가 엄청느리다.

Git Bash 아이콘(GIT)과 Git Bash를 구동시킨 화면
상단의 MINGW32가 눈에 띈다(=cygwin)


이건 리눅스(Fedora Core 6)에서 받는 모습
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Initialized empty Git repository in /home/st7109/linux-2.6/.git/
remote: Counting objects: 1523321, done.
remote: Compressing objects: 100% (245141/245141), done.
Receiving objects:  43% (661258/1523321), 260.79 MiB | 2.10 MiB/s

이건 msysgit(WinXP Git Bash)에서 받는 모습
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Initialized empty Git repository in c:/Documents and Settings/morpheuz/temp/linux-2.6/.git/
remote: Counting objects: 1523321, done.
remote: Compressing objects: 100% (245141/245141), done.
Receiving objects:  17% (269063/1523321), 154.20 MiB | 42 KiB/s

이건 머.. ㄱ-
msysgit만 쓰고 리눅스에서 안해봤음
git를 엄청 욕할뻔 했다.

'프로그램 사용 > Version Control' 카테고리의 다른 글

svn / svnadmin 도움말  (0) 2010.04.23
CVS / SVN 장단점, 차이점 비교  (6) 2010.04.07
TortoiseGIT  (0) 2010.03.18
SVN repository 어떻게 구성하지?  (2) 2010.03.08
SVN의 장점  (0) 2009.09.19
Posted by 구차니
GIT는 병렬분산처리 어쩌구 저쩌구
...
간단하게 Linus Torvalds 가 커널 소스관리 편하게 하려고 만든녀석같다.


아무튼 아직 MS용은 없었던걸로 알았는데
오늘검색해보니 google code에서 진행되는 프로젝트로
git for windows / TortoiseGIT 란게 생겨났다.

로고가 흐린건, 빗방울 효과 때문임 ㄱ-

나처럼 msysgit를 먼저 안깐 사람을 위한 기본경로
C:\Program Files\Git\bin


msysgit는 일종의 cygwin 기반의 git 이다.

msysgit의 설정. 귀찮아서 그냥 Use Git Bash only로..

TortoiseGIT는 엄밀하게는 GUI Frontend 이고
이로인해 windows용 GIT를 별도로 설치해야만 한다.(이건 조금 불편)

[링크 : http://code.google.com/p/tortoisegit/]
[링크 : http://code.google.com/p/msysgit/]
Posted by 구차니
SVN은 리파지터리(repository, 이하 저장소) 별로 revision이 올라간다.
다르게 말하자면, 저장소 하나별로 프로젝트를 구성하는게
roll-back 이나, 관리에 유용하다는 점이다.

물론 SVN은 개인적으로 단일 프로젝트에만 사용했지,
단일 - 복합 프로젝트에는 사용해보지 못해서 이것이 정답이다! 라고 하긴 힘들지만
CVS에 비해서 저장소 관리에 모호함이 있다.

CVS는 파일별로 revision이 붙는데,
SVN은 commit 별로 revision이 증가한다.

다르게 말하면 SVN은 하나를 커밋하는 행위가
CVS에서 커밋 후 tag를 붙이는것과 동일한 행위가 된다.

이런 이유로, 하나의 프로젝트에 사용되는 소스 저장용 / 개발환경 저장용 저장소 구성에 있어
약간의 차이점이 생길수 밖에 없다.

일단 /home/cvs 에 구성했다고 할경우
cvs 아래에 여러가지 소스를 디렉토리 별로 구성을 할 수 있다.
물론 atomic commit이라던가, tagging은 문제가 있겠지만,
한번에 모든 저장소를 볼수 있기 때문에 사용상에 상당한 잇점으로 작용한다.

그에비해 svn을 하나의 저장소 아래 여러개 프로젝트로 할 경우,
어떻게 보면 svn을 쓰는 의미가 없어질 정도가 된다.

예를들어 linux kernel / uboot source / nfs target / MTD target을 구성할 경우
CVS는 Filesystem을 CVS에 넣고 각각 디렉토리로 구성해도 상관없지만(파일별로 하니까)
SVN에 이런식으로 구성을 하면, 하나의 커밋 별로 revision이 증가하는건 아무런 의미가 없게된다.

아무튼
/home/svn/프로젝트 1
/home/svn/프로젝트 2
/home/svn/프로젝트 3

이런식으로 구성을 하고,
svnserve -d -r /home/svn
으로 한다음, 개별 프로젝트로 이름을 알아내서 쓰는게 (불편하지만) 낫지 않을까하는 생각이 든다.


혹시.. 웹에서 cvsweb 처럼 보여주는 게 있을려나?
[링크 : http://freshmeat.net/projects/svnweb/]
[링크 : http://freshmeat.net/projects/cvsweb/]
[링크 : http://www.viewvc.org/]

[링크 : http://svnbook.red-bean.com/en/1.4/index.html]
    [링크 : http://svnbook.red-bean.com/en/1.4/svn.reposadmin.planning.html]

'프로그램 사용 > Version Control' 카테고리의 다른 글

GIT는 리눅스에서 받으시는걸 추천합니다.  (0) 2010.03.18
TortoiseGIT  (0) 2010.03.18
SVN의 장점  (0) 2009.09.19
svn tagging/branching  (0) 2009.08.20
SVN repository 구조  (0) 2009.05.11
Posted by 구차니
오프라인에서도 마지막에 서버에서 받은 것과 diff 할 수 있다!

2010.02.02 추가
(cvs에서는 온라인이 아니라면 비교해 볼수도 없다.)
2009/05/08 - [프로그램 사용/SVN/CVS] - SVN의 단점

Posted by 구차니
SVN의 태그/브랜치는 CVS의 태그/브랜치와 다르다.
CVS의 태그/브랜치는 version에 박히는 것이라면은,
SVN의 태그/브랜치는 저장소에 복사를 하는 것이다.

그런 의미로 굳이
아래의 구조가 아니어도 상관이 없고, 사용자가 관리하기 편한대로 구조를 잡아도 된다는 것이다.




아무튼 태그/브랜치는 TortoiseSVN의 context-menu에서 Branch/tag로 들어갈 수 있으며

Branch/Tag를 누르면 아래의 다이얼로그가 뜨면서 복사할 URL을 물어본다.
기본적인 repository 구조라면, trunk 대신 tags/tag_number로 입력해준다.


그러면 그 위치로 현재 리비전을 복사해서, 새로운 tag를 생성한다.
(물론 내부적으로 복사하므로 매우 빠르고, 실제 데이터 크기가 크게 늘어나지도 않는다)


Repository Browser로 확인해 본, 태그 디렉토리
위에서 한대로 0.0.1 버전을 생성하였다.



Posted by 구차니
Recommended Repository Layout
While Subversion's flexibility allows you to lay out your repository in any way that you choose, we recommend that you create a trunk directory to hold the “main line” of development, a branches directory to contain branch copies,
and a tags directory to contain tag copies. For example:

$ svn list file:///var/svn/repos
/trunk
/branches
/tags

You'll learn more about tags and branches in Chapter 4, Branching and Merging. For details and how to set up multiple projects, see the section called “Repository Layout” and the section called “Planning Your Repository Organization” to read more about project roots.

[출처 : svnbook.red-bean.com/nightly/en/svn-book.pdf]

cvs2svn으로 변환해보니 저러한 구조가 나왔는데, 아무생각없이 저 391장에 이르는 문서를 대충 넘기다 보니
정말 아무생각없이 넘어간 듯 하다.(38페이지)



브랜치쪽 역시.. 그냥 그림만 봤지 자세한 내용을 안봤더니..(106페이지)

'프로그램 사용 > Version Control' 카테고리의 다른 글

SVN의 장점  (0) 2009.09.19
svn tagging/branching  (0) 2009.08.20
SVN과 CVS 저장소 용량비교(compare Repository Size of CVS & SVN)  (0) 2009.05.11
cvs2svn 사용방법  (0) 2009.05.10
SVN의 단점  (0) 2009.05.08
Posted by 구차니
SVN은 바이너리 타입으로 데이터를 저장한다.
그리고 데이터는 zlib를 사용하여 압축하기 때문에 텍스트의 경우 상당한 공간 절약 효과가 있다 (CVS 대비)

테스트 삼아 CVS -> SVN 변환하면서 어느정도 용량의 차이가 있을까 궁금해서 캡쳐를 해보았다.


보시다시피, SVN은 CVS를 변환한 것임에도 불구하고 거의 1/4 크기 정도 밖에 되지 않는다. (25% 크기로 압축됨)

[참고 : http://stackoverflow.com/questions/458182/does-svn-compress-the-binary-content]


'프로그램 사용 > Version Control' 카테고리의 다른 글

svn tagging/branching  (0) 2009.08.20
SVN repository 구조  (0) 2009.05.11
cvs2svn 사용방법  (0) 2009.05.10
SVN의 단점  (0) 2009.05.08
svn 저장소의 위치  (0) 2009.05.08
Posted by 구차니