(如果有eclipse项目A,项目B,那么项目A和B,是testsvn资源库的下属,这点和以前的理解不一样)
cd /home
sudo groupadd svn 新建svn组
sudo usermod -a -G svn neo 把neo加到svn组成员中去
sudo chgrp -R svn /home/svn 递归将svn及其子目录/文件的组拥有者设置成svn组
sudo chmod -R g+w /home/svn 递归将svn及其子目录/文件的组拥有者(svn)赋予w的权限(是否应该递归,会不会影响安全?)
sudo gedit /home/svn/passwd-team 创建密码文件
内容如下:
[users]
michal = somepassword
jimmy = anotherpassword
craig = yetanotherpassword
由于这个密码文件是明码保存的,所以设置成只有root可以访问
sudo chmod 600 /home/svn/passwd-team
编辑svnserve.conf这个文件
gedit /home/svn/testsvn/conf/svnserve.conf
改成
[general]
anon-access = none 设置不允许匿名访问
password-db = /home/svn/passwd-team
realm = Team
注意,以上参数名称, 必须在每行的顶头写,前面不能有空格。比如anon-access前如果加了空格,则svn会提示"svn: /home/svn/upos/conf/svnserve.conf:12: Option expected"
附件是启动脚本, 需根据实际情况修改
This tutorial describes setting up a Subversion server on an Ubuntu system and configuring it for use by a group of developers. The goal is to allow each member of a development team to access the Subversion repositories from a remote location (e.g., a workstation at home), using either the svn or svn+ssh protocol.
It is assumed that you already have a basic Ubuntu server running, and that the other developers can connect to it. If you want to allow them to access the Subversion server with the secure svn+ssh protocol, then each developer must also be able to login to your machine with SSH.
Begin by installing the Subversion package:
$ sudo apt-get install subversion
You're going to need a directory for your repositories, as well as other Subversion-related files. Most people use /home/svn
or /usr/local/svn
for this purpose, and you can choose either. I personally prefer /usr/local/svn
over /home/svn
, as I like to keep /home for home directories of real users of the system.
$ sudo mkdir /usr/local/svn
Inside this directory, create another one to hold your repositories:
$ sudo mkdir /usr/local/svn/repos
Now, you need to set some access permissions on those directories. You only want to allow certain users of your system (that is, yourself and the other developers) to access the repositories, so add a new group for those users. Name the group svn
.
$ sudo groupadd svn
Then, change the group ownership of /usr/local/svn/repos
to the new group using the chgrp
command:
$ sudo chgrp svn /usr/local/svn/repos
The members of the svn
group also need write access to the repos
directory, so use chmod
to add the write permission for the group:
$ sudo chmod g+w /usr/local/svn/repos
Additionally, you need to make sure that all new files and directories created in the repos
directory (in other words, anything committed to the repositories) will also be owned by the group. To accomplish this, use chmod
again to set the set-group-ID bit on the directory, which causes any file created inside it to have the same group ownership as the directory itself. Effectively, everything in repos
will belong to the svn
group.
$ sudo chmod g+s /usr/local/svn/repos
OK, so you now have the repositories directory with proper permissions, ready to be used by the svn
group. Go ahead and add yourself to the group:
$ sudo usermod -a -G svn michal
However, your new group membership will not be effective for the current session, so you need to log out and log back in. When you're back, you can verify that your account is recognized as a member of the svn group:
$ groups michal adm dialout cdrom plugdev lpadmin admin sambashare svn
If the other developers have user accounts on your server, add them to the group too:
$ sudo usermod -a -G svn jimmy $ sudo usermod -a -G svn craig
If they don't, they will still be able to access the repositories, but only using the basic svn protocol, not the secure svn+ssh method.
You can now create a repository. In the following steps, I'll demonstrate how to create a simple test repository containing one text file, and how to check out and commit files. If you're not familiar with Subversion, then this could be a good exercise to learn the basics. Otherwise, you can skip all the test checkouts and commits and just create the repository for your project.
The repository will be a subdirectory in the repos
directory, and will have its group ownership set to svn
(thanks to the chmod g+s
you did earlier). However, that's not all – you also need to make sure the repository will be group writable, so that the other members of the svn
group will be able to commit files. To do this, set the umask to 002
:
$ umask 002
This command sets the new file mode creation mask which controls the default permissions of any new file that you create. The default value is 022
and it corresponds to read/write permissions for the file owner, and read permissions for the group and others. The new value, 002
, also gives write permissions to the group, which is just what you need.
Create the repository using the svnadmin
command:
$ svnadmin create /usr/local/svn/repos/test
And set back the default umask:
$ umask 022
So you now have an empty repository, waiting for you to commit something to it. But, before you do this, you need to check out the current version (i.e., the empty directory) to create a working copy.
$ svn checkout file:///usr/local/svn/repos/test Checked out revision 0.
The working copy has been checked out to a new directory named test
. Go ahead and create a simple "hello world" text file in that directory:
$ cd test $ echo 'Hello, World!' > hello.txt
Then, add it to version control with the svn add
command:
$ svn add hello.txt A hello.txt
Finally, commit it using svn commit
:
$ svn commit -m "Added a 'hello world' text file." Adding hello.txt Transmitting file data . Committed revision 1.
The hello.txt
file is now in the repository.
Remote repository access with the svn protocol requires you to use svnserve
, a Subversion server program. Each repository has a svnserve
configuration file (stored in the conf
subdirectory) which controls how the repository can be accessed with svnserve
.
First, create a passwords file that lists the users of the repository and their passwords. This will be a common passwords file for your development team and you will be able to use it with multiple repositories.
$ sudo gedit /usr/local/svn/passwd-team
Here's a sample passwords file. Each line (except the first one, which is the configuration section name) defines a user name and the corresponding password.
[users] michal = somepassword jimmy = anotherpassword craig = yetanotherpassword
Since the passwords are stored unencrypted, it's important that you protect the passwords file by setting the proper permissions. The file should not be readable by anyone except the owner (which is root
), so change its mode to 600
:
$ sudo chmod 600 /usr/local/svn/passwd-team
Then, open the svnserve
configuration file in the test repository:
$ gedit /usr/local/svn/repos/test/conf/svnserve.conf
There's probably some default configuration in the file, but you can just remove everything and enter this:
[general] anon-access = none password-db = /usr/local/svn/passwd-team realm = Team
The anon-access = none
line denies access to the repository to unauthenticated users (by default, they are allowed read access, so they can do checkouts). The password-db
setting tells svnserve where to look for the passwords file when authenticating users, and the realm
setting defines the name of the authentication realm.
OK, the configuration is ready, so you can now launch svnserve
.
$ sudo svnserve -d --foreground -r /usr/local/svn/repos
The command-line options tell svnserve
to run in daemon mode (-d
) as a foreground process (--foreground
), and to look for repositories in the repos
dir that was created earlier (-r /usr/local/svn/repos
). Normally the program should be running in the background (that's what daemon processes do), but at this moment you only need to test it, so it's more convenient to run it in the foreground, where you can easily kill it with Ctrl
+C
.
Now, try accessing the repository using the svn protocol. You can try it on another machine over the network, or on the same computer (in another terminal). In the latter case, make sure you're not doing the checkout in the same directory where the previous test working copy was checked out, because it won't work – either delete the test directory, or cd
to some other location.
Enter the following svn checkout
command, replacing 192.168.10.11
with the IP address of your Subversion server (if you're testing on the same machine, you can use 127.0.0.1
):
$ svn checkout svn://192.168.10.11/test --username jimmy
The server will ask you for password:
Authentication realm: <svn://192.168.10.11:3690> Team Password for 'jimmy':
Then, it proceeds with the checkout.
A test/hello.txt Checked out revision 1.
And there's your working copy. Now, check if it works the other way – try modifying the file and committing it back to the repository. Open hello.txt
with a text editor and add some text:
$ cd test $ gedit hello.txt
When you're done, commit it:
$ svn commit -m "Modified the hello.txt file." Sending hello.txt Transmitting file data . Committed revision 2.
Sweet, it works both ways.
Setting up your Subversion server for svn+ssh access is simple, as it doesn't even require using the svnserve
program. Assuming you have a SSH server running on the Subversion machine, and the other developers can login to it, you don't have to configure anything – just set up the repository.
You can just go ahead and check out the test project. The checkout operation is slightly different with the svn+ssh access method. First, you must specify the full path to the repository in the checkout URL:
$ svn checkout svn+ssh://192.168.10.11/usr/local/svn/repos/test --username jimmy
Then, when the server asks you for a password, you need to enter the user's SSH password, not the one from the passwd-team
file.
[email protected]'s password:
And there it goes:
A test/hello.txt Checked out revision 2.
From here, you can use your working copy the same way as with the svn
protocol.
If you plan on using svnserve
in the long run, you probably don't want to start it from the command-line every time the server is rebooted. The proper way to start system services is with init scripts located in the /etc/init.d
directory.
The Subversion package for Ubuntu does not include an init script, so you have to make one yourself. Or, you can download this init script , written by yours truly. Save the script as /etc/init.d/svnserve
and make it executable:
$ sudo chmod +x /etc/init.d/svnserve
If you chose anything other than /usr/local/svn/repos
for the repositories directory, make sure to change the path in the init script.
Run update-rc.d
to install the script:
$ sudo update-rc.d svnserve defaults Adding system startup for /etc/init.d/svnserve ... /etc/rc0.d/K20svnserve -> ../init.d/svnserve /etc/rc1.d/K20svnserve -> ../init.d/svnserve /etc/rc6.d/K20svnserve -> ../init.d/svnserve /etc/rc2.d/S20svnserve -> ../init.d/svnserve /etc/rc3.d/S20svnserve -> ../init.d/svnserve /etc/rc4.d/S20svnserve -> ../init.d/svnserve /etc/rc5.d/S20svnserve -> ../init.d/svnserve
And that's it – svnserve
will be started automatically when your system boots up. To start it manually, run this command:
$ sudo /etc/init.d/svnserve start
另外一篇 http://blog.sina.com.cn/s/blog_3eba8f1c0100dqk1.html
一、SVN安装
1.安装包
$ sudo apt-get install subversion
2.添加svn管理用户及subversion组
$ sudo adduser svnuser
$ sudo addgroup subversion
$ sudo addgroup svnuser subversion
同步程序思路 :用户提交程序到SVN,SVN触发hooks,按不同的hooks进行处理,这里用到的是post-commit,利用post-commit到代码检出到SVN服务器的本地硬盘目录,再通过rsync同步到远程的WEB服务器上。
知识点:
1、SVN的hooks
# start-commit 提交前触发事务
# pre-commit 提交完成前触发事务
# post-commit 提交完成时触发事务
# pre-revprop-change 版本属性修改前触发事务
# post-revprop-change 版本属性修改后触发事务
通过上面这些名称编写的脚本就就可以实现多种功能了,相当强大。
2、同步命令rsync的具体参数使用
3、具有基个语言的编程能力bash python perl都可以实现
post-commit具体实现细节
post-commit脚本
编辑文件:sudo vim /home/svn/fitness/hooks/post-commit
注意:编辑完成post-commit后,执行:sudo chmod 755 post-commit
内容:
#!/bin/sh
export LANG=zh_CN.UTF-8
sudo /usr/bin/svn update /var/www/www --username mirze --password 123456
或
#Set variable