SVN의 태그/브랜치는 CVS의 태그/브랜치와 다르다.
CVS의 태그/브랜치는 version에 박히는 것이라면은,
SVN의 태그/브랜치는 저장소에 복사를 하는 것이다.
그런 의미로 굳이
아래의 구조가 아니어도 상관이 없고, 사용자가 관리하기 편한대로 구조를 잡아도 된다는 것이다.
아무튼 태그/브랜치는 TortoiseSVN의 context-menu에서 Branch/tag로 들어갈 수 있으며
Branch/Tag를 누르면 아래의 다이얼로그가 뜨면서 복사할 URL을 물어본다.
기본적인 repository 구조라면, trunk 대신 tags/tag_number로 입력해준다.
그러면 그 위치로 현재 리비전을 복사해서, 새로운 tag를 생성한다.
(물론 내부적으로 복사하므로 매우 빠르고, 실제 데이터 크기가 크게 늘어나지도 않는다)
Repository Browser로 확인해 본, 태그 디렉토리
위에서 한대로 0.0.1 버전을 생성하였다.
4.19. Branching / Tagging
One of the features of version control systems is the ability to isolate
changes onto a separate line of development. This line is known as a branch. Branches are often used to try out new features
without disturbing the main line of development with compiler errors and bugs.
As soon as the new feature is stable enough then the development branch is merged back into the main branch (trunk).
Another feature of version control systems is the ability to mark particular
revisions (e.g. a release version), so you can at any time recreate a certain
build or environment. This process is known as tagging.
Subversion does not have special commands for branching or tagging, but uses
so-called “cheap copies” instead. Cheap copies are
similar to hard links in Unix, which means that instead of making a complete
copy in the repository, an internal link is created, pointing to a specific
tree/revision. As a result branches and tags are very quick to create, and take
up almost no extra space in the repository.
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.
You'll need the following build tools to compile Subversion:
* autoconf 2.58 or later (Unix only)
* libtool 1.4 or later (Unix only)
* a reasonable C compiler (gcc, Visual Studio, etc.)
Subversion also depends on the following third-party libraries:
* libapr and libapr-util (REQUIRED for client and server)
The Apache Portable Runtime (APR) library provides an
abstraction of operating-system level services such as file
and network I/O, memory management, and so on. It also
provides convenience routines for things like hashtables,
checksums, and argument processing. While it was originally
developed for the Apache HTTP server, APR is a standalone
library used by Subversion and other products. It is a
critical dependency for all of Subversion; it's the layer
that allows Subversion clients and servers to run on
different operating systems.
* SQLite (REQUIRED for client and server)
Subversion uses SQLite to manage some internal databases.
* libz (REQUIRED for client and server)
Subversion uses zlib for compressing binary differences.
These diff streams are used everywhere -- over the network,
in the repository, and in the client's working copy.
* libserf (OPTIONAL for client)
The Serf libraries both allow the Subversion client
to send HTTP requests. This is necessary if you want your
client to access a repository served by the Apache HTTP
server. There is an alternate 'svnserve' server as well,
though, and clients automatically know how to speak the
svnserve protocol. Thus it's not strictly necessary for your
client to be able to speak HTTP... though we still recommend
that your client be built to speak both HTTP and svnserve
protocols.
* OpenSSL (OPTIONAL for client and server)
OpenSSL enables your client to access SSL-encrypted https://
URLs (using libserf) in addition to unencrypted http:// URLs.
To use SSL with Subversion's WebDAV server, Apache needs to
be compiled with OpenSSL as well.
* Berkeley DB (OPTIONAL for client and server)
There are two different repository 'back-end'
implementations. One implementation stores data in a flat
filesystem (known as FSFS); the other implementation stores
data in a Berkeley DB database (known as BDB). When you
create a repository, you have the option of specifying a
storage back-end. The Berkeley DB back-end will only be
available if the BDB libraries are discovered at compile
time.
* libsasl (OPTIONAL for client and server)
If the Cyrus SASL library is detected at compile time, then
the svn client (and svnserve server) will be able to utilize
SASL to do various forms of authentication when speaking the
svnserve protocol.
* Python, Perl, Java, Ruby (OPTIONAL)
Subversion is mostly a collection of C libraries with
well-defined APIs, with a small collection of programs that
use the APIs. If you want to build Subversion API bindings
for other languages, you need to have those languages
available at build time.
* KDELibs, GNOME Keyring (OPTIONAL for client)
Subversion contains optional support for storing passwords in
KWallet (KDE 4) or GNOME Keyring.
To create a new Subversion repository by converting an existing CVS repository, run the script like this: $ cvs2svn --svnrepos NEW_SVNREPOS CVSREPOS
To create a new Subversion repository containing only trunk commits,
and omitting all branches and tags from the CVS repository, do
$ cvs2svn --trunk-only --svnrepos NEW_SVNREPOS CVSREPOS
To create a Subversion dumpfile (suitable for 'svnadmin load') from a CVS repository, run it like this:
$ cvs2svn --dumpfile DUMPFILE CVSREPOS
To use an options file to define all of the conversion parameters, specify --options:
$ cvs2svn --options OPTIONSFILE
As it works, cvs2svn will create many temporary files in a temporary
directory called "cvs2svn-tmp" (or the directory specified with
--tmpdir). This is normal. If the entire conversion is successful,
however, those tempfiles will be automatically removed. If the
conversion is not successful, or if you specify the '--skip-cleanup'
option, cvs2svn will leave the temporary files behind for possible
debugging.
cvs2svn은 cvs 리파지터리를 svn으로 변환해주는 툴이다.
변환과정중에 하나라도 잘못된 ,v 파일(cvs의 history 파일)이 있으면 중지되고,
한글을 사용했을 경우, encoding 문제로 인해서 pass 2에서 문제가 발생한다.
ERROR: There were warnings converting author names and/or log messages
to unicode (see messages above). Please restart this pass
with one or more '--encoding' parameters or with '--fallback-encoding'.
$ man cvs2svn --encoding=encoding
Use encoding as the encoding for filenames, log messages, and
author names in the CVS repos. This option may be specified mul-
tiple times, in which case the encodings are tried in order until
one succeeds. Default: ascii. See
http://docs.python.org/lib/standard-encodings.html for a list of
other standard encodings.
--fallback-encoding=encoding
If none of the encodings specified with --encoding succeed in
decoding an author name or log message, then fall back to using
encoding in lossy 'replace' mode. Use of this option may cause
information to be lost, but at least it allows the conversion to
run to completion. This option only affects the encoding of log
messages and author names; there is no fallback encoding for
filenames. (By using an --options file, it is possible to spec-
ify a fallback encoding for filenames.) Default: disabled.
예를 들어
/home/svn 이 svn의 저장소를 놓을 위치이고
그 아래에 각각의 프로젝트가 들어 간다면
저장소의 위치는 /home/svn이다.
svnserve -d로 구동할때 의 경로는 /home/svn이 되고
svn으로 checkout을 할때의 경로는 각 프로젝트를 넣어 준다.
예를 들어
/home/svn/proj1
/home/svn/proj2
가 있다면
svn://svnserver.ip.addr/proj1
이런식으로 접속하면 프로젝트에 대해서 보인다.
음.. 그런데 굳이 각각의 저장소로 여러개의 저장소에 구분을 해야 하는 이유가 있을려나..
그냥 repos 이런식으로 하나의 저장소만을 만들고
그 아래에 디렉토리/폴더로 구분하면 될텐데 말이다...
아무튼 각 저장소별 ./conf 디렉토리에는
passwd / auth / svnserve.conf가 존재하며
svnserve.conf의 주석 몇개와
passwd에 사용자 계정을 추가하면
svn:// 식으로 접속하여 사용이 가능하다.
svn+ssh://은 아직.. OTL
svnserve.conf
### This file controls the configuration of the svnserve daemon, if you
### use it to allow access to this repository. (If you only allow
### access through http: and/or file: URLs, then this file is
### irrelevant.)
### Visit http://subversion.tigris.org/ for more information.
[general]
### These options control access to the repository for unauthenticated
### and authenticated users. Valid values are "write", "read",
### and "none". The sample settings below are the defaults. anon-access = read auth-access = write
### The password-db option controls the location of the password
### database file. Unless you specify a path starting with a /,
### the file's location is relative to the directory containing
### this configuration file.
### If SASL is enabled (see below), this file will NOT be used.
### Uncomment the line below to use the default password file. password-db = passwd
### The authz-db option controls the location of the authorization
### rules for path-based access control. Unless you specify a path
### starting with a /, the file's location is relative to the the
### directory containing this file. If you don't specify an
### authz-db, no path-based access control is done.
### Uncomment the line below to use the default authorization file.
# authz-db = authz
### This option specifies the authentication realm of the repository.
### If two repositories have the same authentication realm, they should
### have the same password database, and vice versa. The default realm
### is repository's uuid.
# realm = My First Repository
[sasl]
### This option specifies whether you want to use the Cyrus SASL
### library for authentication. Default is false.
### This section will be ignored if svnserve is not built with Cyrus
### SASL support; to check, run 'svnserve --version' and look for a line
### reading 'Cyrus SASL authentication is available.'
# use-sasl = true
### These options specify the desired strength of the security layer
### that you want SASL to provide. 0 means no encryption, 1 means
### integrity-checking only, values larger than 1 are correlated
### to the effective key length for encryption (e.g. 128 means 128-bit
### encryption). The values below are the defaults.
# min-encryption = 0
# max-encryption = 256
passwd
### This file is an example password file for svnserve.
### Its format is similar to that of svnserve.conf. As shown in the
### example below it contains one section labelled [users].
### The name and password for each user follow, one account per line.
TortoiseSVN에는 Diff / Merge 툴이 내장되어 있다.
Diff/Merge 프로그램은 외관상으로는 WinMerge와 유사하고, 동일 프로젝트를 변형해서 사용하는게 아닐까라는 생각이 든다.
아무튼 이러한 개인적인 추측은 패스하고~ 장점과 단점을 말하자면 다음과 같다.
WinMerge
TortoiseMerge
Syntax Highlight
지원
미지원
UTF-8 지원
지원
미지원
네비게이션 부분 확대
미지원
지원
일반적인 소스를 다루는 경우에는 UTF-8 을 굳이 지원해야 할 필요는 없지만,
현재 다국어지원 작업을 하는데 UTF-8을 지원하지 않는 다면 아래와 같이 선택할 경우에 글씨가 깨지는 문제가 발생한다.
TortoiseMerge - 좌측의 네비게이션 부분확대가 매력적이다. (확대해서 비교해 보세요!!)
색상이 있는 줄이 차이점 부분이 확대된 것이고, 아래의 흐릿한 선들이 원래 크기의 차이점 부분표시이다.
WinMerge - 네비게이션을 제외하면 전반적으로 WinMerge가 낫다
구버전의 TortoiseCVS의 경우에는, 기본 비교/병합 프로그램이 없어, 무조건 하나만 입력이 가능한 단점이 있었지만,
TortoiseSVN은 내장 비교/병합 프로그램이 있어서, 사용하지 않더라도 외부 프로그램의 링크는 사라지지 않아 좋다.
남아있는 External Link (화면 배색문제로, 일반적인 pc에서는 회색으로 보임)
또 다른 TortoiseSVN의 내장 비교툴로 IDiff가 있다(Image Diff)
말그대로 이미지를 비교 하는 것인데, I가 굴림체인지라 Diff밖에 눈에 안들어 온다.
위의 이미지가 이미지 비교 프로그램, 아래는 소스 비교 프로그램
이 포스트에 들어간 이미지 a.png와 c.png를 비교한 화면이다
비교 옵션 중 겹쳐보기로 본 비교화면 (Overlay Mode)
비교 옵션 중 혼합겹쳐보기로 본 비교화면 (Overlay Mode + Alpha Blend)
CVS만 2년 정도 사용했다.
물론 branch 까지는 사용해보지 않았고,
주로 사용하던 기능은 history와 tag 뿐이었다.
아무튼 이렇게 CVS만 쓰다가 SVN을 사용해봤는데,
처음 사용할때의 어색함인지, 상당히 다른 느낌이 든다.
일단 CVS는 module 단위였는데 SVN은 그러한 구분이 없다는 사실.
어쩌면 구형 TortoiseCVS를 사용해서 그럴지도 모르겠다는 생각이 든다.
신형 TortoiseCVS의 경우에는 물론 module단위로 만들기는 하지만,
module 목록을 combobox가 아닌 listbox로 보여 주기 때문에, 기존 버전보다는
확연히 구분되어 있다는 느낌이 적게 들었다.
하지만, SVN은 이러한 '프로젝트'의 느낌보다는, 이력이 남는 '파일 저장소'라는 느낌이 강하게 든다.
(아마 파일 이동의 편의성과, checkout시 URL로 입력하는 특성때문일 것이다)
UFO:AI 한글화 프로젝트 참여중인데, SVN의 사용은 처음이라 이래저래 적응이 안된다.
가장 큰 것으로는
CVS의 history라는 것이 SVN에서는 Show Log로 바뀌었다는 것이다.
그리고 SVN은 하나의 커밋이나 수정사항이 있을때, 전체의 리비전이 변경되므로,
파일 각각이 아닌 SVN repository 전체에 대한 Log가 존재하게 된다
(사용이 미숙해서 그럴지도 모르지만 TortoiseCVS에서는 파일 단위로 밖에 보지 못했다)
Context-menu 이다. 주로 사용하는 것은
프로젝트 전체의 업데이트인 SVN Update와
프로젝트 전체의 수정 업로드인 SVN Commit 그리고
프로젝트의 변경사항을 볼수 있는 Show Log 이다.
위의 이미지는 프로젝트 전체의 Show Log 결과이다.
프로젝트에서 추가 / 삭제된 파일등과 전체의 Revision이 표기된다.
자막 번역 파일 하나의 내역이다. 자세히 보면 알겠지만, Revision이 1씩 증가하지 않는다.
리비전에서 변동사항이 있을 수도 있고, 없을 수도 있기 때문에, 파일을 Show Log 하면
위와 같이 나오지 않는 사항들을 볼 수 있다.
