$ su -
$ apt-get install subversion
$ mkdir /svn-repos
$ groupadd svn
$ cd /svn-repos
$ svnadmin create project_name
$ chgrp -R svn project_name
$ chmod -R g+w project_name
by sminchoi 2011. 1. 26. 21:00
우선 자동 로그인을 원하는 계정으로 인증키 생성

$ ssh-keygen -t rsa
$ cd .ssh
$ mv id_rsa.pub authorized_keys

이제 아래와 같이 자동 접속이 되는지 확인 가능
$ ssh localhost
간혹 안될 경우에는
/etc/ssh/sshd_config에서 "PubkeyAuthentication yes"와 "AuthorizedKeysFile .ssh/authorized_keys" 확인해야 한다고하나,
AuthorizedKeysFile은 주석처리되어 있어도 상관없이 잘되었음

id_rsa 파일을 (id_rsa.pub 파일 아님) 가져와서
puttygen 실행하여 Conversions -> Import key 실행한 후, Save private key로 적당한 이름의 *.ppk 파일을 생성
(SSH-2 RSA type으로 했음)

pageant.exe 실행하여 트레이 아이콘 우클릭하여 Add Key 메뉴로 위에서 생성한 *.ppk 파일을 등록
pageant가 상주하면서 자동으로 로그인 하게 해줌

실제 putty를 이용해 접속해보면 계정id만 입력하면 생성된 키로 자동 로그인하는것을 확인 가능함
계정id 입력하는것도 귀찮다면, putty설정에서 "접속 -> 데이터"의 로그인 정보에 자동 로그인 사용자 id를 입력해서
id/passwd 입력없이 자동 로그인이 가능함

tortoiseSVN에서는 svn+ssh://id@host/svn-repos/... 식으로 접속해 자동 로그인 가능
by sminchoi 2011. 1. 26. 19:42
한 저장소 안에 프로젝트별로 관리하는 경우에는 리비전 넘버는 저장소 기준으로 증가하므로
프로젝트 별로 리비전 넘버가 띄엄띄엄 올라가게 된다. (바꿔말하면 굳이 리비전 넘버에는 신경을 안 써도 될듯)
다만 조금이라도 연관성이 있다던가 코드의 일부라도 공유할 가능성이 있다면 한 저장소 안에 프로젝트별로 해도 되나,,,
전혀 상관없는 프로젝트라면 차라리 저장소를 따로 만들어서 관리하는게 더 나을듯함

http://subversion.apache.org/faq.html#multi-proj

How do I manage several different projects under Subversion?

It depends upon the projects involved. If the projects are related, and are likely to share data, then it's best to create one repository with several subdirectories like this:

	$ svnadmin create /repo/svn
	$ svn mkdir file:///repo/svn/projA
	$ svn mkdir file:///repo/svn/projB
	$ svn mkdir file:///repo/svn/projC

If the projects are completely unrelated, and not likely to share data between them, then it's probably best to create separate and unrelated repositories.

	$ mkdir /repo/svn
	$ svnadmin create /repo/svn/projA
	$ svnadmin create /repo/svn/projB
	$ svnadmin create /repo/svn/projC

The difference between these two approaches is this (as explained by Ben Collins-Sussman <sussman@collab.net>):

  • In the first case, code can easily be copied or moved around between projects, and the history is preserved. ('svn cp/mv' currently only works within a single repository.)
  • Because revision numbers are repository-wide, a commit to any project in the first case causes a global revision bump. So it might seem a bit odd if somebody has 'projB' checked out, notices that 10 revisions have happened, but projB hasn't changed at all. Not a big deal, really. Just a little weird at first. This used to happen to svn everytime people committed to rapidsvn, when rapidsvn was in the same repository. :-)
  • The second case might be easier to secure; it's easier to insulate projects from each other (in terms of users and permissions) using Apache's access control. In the 1st case, you'll need a fancy hook script in the repository that distinguishes projects ("is this user allowed to commit to this particular subdir?") Of course, we already have such a script, ready for you to use.

by sminchoi 2011. 1. 26. 16:48
| 1 |