看完这篇文章后，两个字：郁闷。
理由是我刚刚装完visualSVN，结果就看到这篇文章了，由于已经有三个人在用这个SVN，想再更换也不方便，所以就不再更换了。不过文章还是要转一下的，作个备份还是很重要的，下次再换成标准的SVN服务器。
原文链接：http://www.phpweblog.net/fuyongjie/archive/2009/01/05/6265.html（由于原文也是转摘的，但我不知道最初的地址，只能用这个地址了）
原文如下：
作者： rocksun 来源：Subversion
Subversion安装成service
以前的svnserve要想成为windows服务，必须依赖于svnservice或其他工具。从Subversion1.4开始，Subversion本身就集成Windows服务的工具。
1，安装svnservice
在Windows NT中（包括Windows XP, Windows 2000, Windows 2003 Server）本身包含了一个安装服务的工具，叫做"Service Control"，也就是sc.exe。
例如我的Subversion安装在"D:\Subversion"，版本库在"D:\svnroot"，而我希望对应的Subversion服务名为svnservice，安装这个svn服务的命令就可以这样写：
sc create svnservice
binpath= "D:\Subversion\bin\svnserve.exe --service -r D:\svnroot"
displayname= "SVNService"
depend= Tcpip |
请注意，因为便于察看，上面的命令分为多行，但在实际执行时应该在一行里。另外，在以前启动svnserve时会使用"-d"选项，也就是守护进程模式，在这里不能使用，会导致服务无法启动。同样，"-i"和"-t"选项也不能使用。
在命令行窗口执行完这个命令之后，服务还没有启动，你可以继续运行"net start svnservice"启动这个服务，然后使用"net stop svnservice"停止服务。
另 外还有两点需要小心处理。首先，如果路径中包括空格，一定要用“\”处理“"”号，例如上面的例子中如果svnserve.exe在“c: \program files\subversion\”中，则命令应该写为“binpath= "\"c:\program files\subversion\bin\svnserve.exe\"”（“”中的内容），整个命令如下，红色部分是改变部分：
sc create svnservice
binpath= "\"D:\program files\Subversion\bin\svnserve.exe\" --service -r D:\svnroot"
displayname= "SVNService"
depend= Tcpip |
其次，sc对选项的格式还有要求，例如“depend= Tcpip”不能写为“depend = Tcpip”或“depend=Tcpip”，也就是“=”前不能有空各，而后面必须有空格。
2，删除服务
如果服务安装的有问题，你可能需要删除服务。要删除前面添加的服务，只需要运行"net start svnservice"，"svnservice"就是我们创建服务时使用的名字。
3，配置服务是自动启动
默认情况下安装的服务不会随Windows的启动而启动，为了使svn服务能够随Windows启动而启动，需要修改一下"sc create"命令（首先要删除），增加"start= auto"选项：
sc create svnservice
binpath= "D:\Subversion\bin\svnserve.exe --service -r D:\svnroot"
displayname= "SVNService"
depend= Tcpip
start= auto |
当然你也可以使用图形化的工具修改服务的属性，你可以在“开始->运行...”中执行"services.msc"，然后在界面中修改。
Subversion的权限控制
1，认证（Authentication）和授权（Authorization）
这两个术语经常一起出现。其中认证的意思就是鉴别用户的身份，最常见的方式就是使用用户名和密码，授权就是判断用户是否具备某种操作的权限，在 Subversion里提供了“authz-db”文件，实现了以路径为基础的授权，也就是判断用户是否有操作对应路径的权限，在Subversion 1.3之后，svnserve和Apache一样都可以使用“authz-db”文件。
2. svnserve下的配置文件
因为本文是以svnserve为例的，所以先介绍一下版本库目录的结构：
D:\SVNROOT\PROJECT1
├─conf
├─dav
├─db
│ ├─revprops
│ ├─revs
│ └─transactions
├─hooks
└─locks |
其中conf下面有三个文件：
authz
passwd
svnserve.conf |
其中的“svnserve.conf”是这个版本库的配置文件，当使用svnserve时，这个配置文件决定了使用什么认证和授权文件：
password-db = passwd
authz-db = authz |
上面的配置说明使用“svnserve.conf”同目录的passwd和authz，其中的password-db指定了用户密码文件，authz-db是我们的授权文件，也就是我们本文主要介绍的文件。
注意：使用Apache作为服务器时，根本就不会参考“svnserve.conf”文件的内容，而是会参考Apache的配置。
3，基于svnserve的版本库文件布局
使用svnserve时，为了管理的方便，应该使用相同的认证和授权文件，所以应该让所有版本库的配置文件svnserve.conf指向同一个password-db和authz-db文件。下面是一个多版本库的目录：
D:\SVNROOT
├─project1
│ ├─conf
│ ├─dav
│ ├─db
│ │ ├─revprops
│ │ ├─revs
│ │ └─transactions
│ ├─hooks
│ └─locks
└─project2
├─conf
├─dav
├─db
│ ├─revprops
│ ├─revs
│ └─transactions
├─hooks
└─locks |
D:\SVNROOT下有两个目录project1和project2，都已经创建了版本库，所以我们修改每个conf目录下的svnserve.conf，使之指向同一个password-db和authz-db文件。
password-db = ..\..\passwd
authz-db = ..\..\authz这样，D:\SVNROOT\passwd和D:\SVNROOT\authz就控制了所有版本库的svnserve访问。另外在 后面的操作中要关闭匿名访问，应该去掉“anon-access = none”前的“#”号，保证只有认证用户可以访问。
注意：还有一点需要注意，那就是svnserve的“realm”的值，在上面的设置下，应该保证所有的版本库使用相同的realm值，这样，对版本库的密码缓存可以在多个版本库之间共享，更多细节见客户端凭证缓存。
4，测试用户和组说明
版本库禁止任何匿名用户的访问，只对认证用户有效。
root:配置管理管理员，对版本库有完全的管理权限。
p1_admin1:project1的管理员，对project1有完全权限。
p1_d1:project1的开发者，对project1的trunk有完全的权限，但是对其中的/trunk/admin目录没有任何权限。
p1_t1:project1的测试者，对project1的trunk有完全的读权限，但是对其中的/trunk/admin目录没有任何权限。
p2_admin1:project2的管理员，对project2有完全权限。
p2_d1:project2的开发者，对project2的trunk有完全的权限，但是对其中的/trunk/admin目录没有任何权限。
p2_t1:project2的测试者，对project2的trunk有完全的读权限，但是对其中的/trunk/admin目录没有任何权限。
对应的组及组的用户：
p1_group_a:p1_admin1
p1_group_d:p1_d1
p1_group_t:p1_t1
p2_group_a:p2_admin1
p2_group_d:p2_d1
p2_group_t:p2_t1 |
5，修改D:\SVNROOT\passwd文件
前面已经说过了，用户和密码文件应该是在D:\SVNROOT\passwd，所以我们为每一位用户设置权限，文件内容如下：
[users]
p1_admin1 = p1_admin1
p1_d1 = p1_d1
p1_t1 = p1_t1
p2_admin1 = p2_admin1
p2_d1 = p2_d1 |
p2_t1 = p2_t1为了便于验证，所有密码和用户名一致，如果你使用的是其他认证方式，这一步可能不同，但是用户名应该都是一样的。
6，配置授权，修改D:\SVNROOT\authz
|
[groups]
# 定义组信息
p1_group_a = p1_admin1
p1_group_d = p1_d1
p1_group_t = p1_t1
p2_group_a = p2_admin1
p2_group_d = p2_d1
p2_group_t = p2_t1
[/]
# 指定所有的版本库默认只读，root可读写
* = r
root = rw
[project1:/]
# 指定对版本库project1根目录的权限
@p1_group_a = rw
@p1_group_d = rw
@p1_group_t = r
[project1:/trunk/admin]
# 指定对版本库project1的/trunk/admin根目录的权限，
# p1_group_a读写，p1_group_d和p1_group_t没有任何权限。
@p1_group_a = rw
@p1_group_d =
@p1_group_t =
[project2:/]
# 指定对版本库project2根目录的权限
@p2_group_a = rw
@p2_group_d = rw
@p2_group_t = r
[project2:/trunk/admin]
# 指定对版本库project1的/trunk/admin根目录的权限
@p2_group_a = rw
@p2_group_d =
@p2_group_t =
|
经过以上设置以后，你会发现一些有趣的事情。当使用用户“p1_d1”，检出project1的trunk时，目录是空的，好像admin目录根本不存在一样，当使用p1_d1用户浏览版本库时，能够看到admin目录，但是其中的内容却无法看到。
关 于中文目录，也是没有问题的，只是注意要把authz文件转化为UTF-8格式，在我的WINXP的UltraEdit里显示的文件格式为U8-DOS， 具体的做法是用UltraEdit打开authz文件，然后选择“文件->转换->ASCII转UTF-8”，然后保存。
再复杂的情况也不过如此，在实际的工作中要首先规划好权限，只赋给用户最小的权限，保证以最小的配置实现最复杂的权限控制。
Subversion备份
版本控制最关键的一件事是保证数据的安全性，不能因为磁盘损坏，程序故障造成版本库无可挽回的错误，为此必须制定较完备的备份策略。在Subversion中，我们有三种备份方式：完全备份，增量备份和同步版本库。
1, 完全备份
最常见和简单的备份就是直接使用拷贝命令，将版本库目录拷贝到备份目录上，就可以了。但是这样不是很安全的方式，因为如果在拷贝时版本库发生变化，将会 造成备份的结果不够准确，失去备份的作用，为此Subversion提供了“svnadmin hotcopy”命令，可以防止这种问题。
还记得我们的版本库目录吗？
D:\SVNROOT
├─project1
│ ├─conf
│ ├─dav
│ ├─db
│ │ ├─revprops
│ │ ├─revs
│ │ └─transactions
│ ├─hooks
│ └─locks
└─project2
├─conf
├─dav
├─db
│ ├─revprops
│ ├─revs
│ └─transactions
├─hooks
└─locks |
如果要把project1备份到d:\svnrootbak目录下，只需要运行：
svnadmin hotcopy d:\svnroot\project1 d:\svnrootbak\project1
但是我们作为配置管理员，必须想办法优化这个过程，如果我们这个目录下有许多版本库，需要为每个版本库写这样一条语句备份，为此我写了下面的脚本，实现备份一个目录下的所有版本库。我们在D:\SVNROOT下创建了两个文件，simpleBackup.bat：
@echo 正在备份版本库%1......
@%SVN_HOME%\bin\svnadmin hotcopy %1 %BACKUP_DIRECTORY%\%2
@echo 版本库%1成功备份到了%2！
这个文件仅仅是对“svnadmin hotcopy”的包装，然后是backup.bat：
echo off
rem Subversion的安装目录
set SVN_HOME="D:\Subversion"
rem 所有版本库的父目录
set SVN_ROOT=D:\svnroot
rem 备份的目录
set BACKUP_SVN_ROOT=D:\svnrootbak
set BACKUP_DIRECTORY=%BACKUP_SVN_ROOT%\%date:~0,10%
if exist %BACKUP_DIRECTORY% goto checkBack
echo 建立备份目录%BACKUP_DIRECTORY%>>%SVN_ROOT%/backup.log
mkdir %BACKUP_DIRECTORY%
rem 验证目录是否为版本库，如果是则取出名称备份
for /r %SVN_ROOT% %%I in (.) do @if exist "%%I\conf\svnserve.conf" %SVN_ROOT%\simpleBackup.bat "%%~fI" %%~nI
goto end
:checkBack
echo 备份目录%BACKUP_DIRECTORY%已经存在，请清空。
goto end
:end
你 在使用的时候，只需要修改backup.bat开头的三个路径，将两个脚本拷贝到“SVN_ROOT”下就可以了。根据以上的配置，你只需要运行 backup.bat，就可以把“SVN_ROOT”下的版本库都备份到“BACKUP_SVN_ROOT”里，并且存放在备份所在日的目录里，例如 “D:\svnrootbak\2006-10-22”。
虽然这部分工作很简单，可是必须有人定时地去执行这个操作（例如每周一凌晨），为了避免发生遗忘的情况，我们可以将这个操作加入到系统的at任务当中去，例如还是上面的环境，为了安装at任务，我们运行：
at 1:00 /every:M D:\svnroot\backup.bat这样在每周一凌晨1:00都会执行这个备份过程。当然备份在本机也是不安全的，你也许需要上传到别的机器，这个就要靠你自己去实现了。
2, 增量备份
尽管完全备份非常简单，但是也是有代价的，当版本库非常巨大时，经常进行完全备份是不现实的，也并不必要，但是一旦版本库在备份之间发生问题，该如何呢，这里我们就用到了增量备份。
增量备份通常要与完全备份结合使用，就像oracle数据库的归档日志，记录着每次Subversion提交的变化，然后在需要恢复时能够回到最新的可用状态。在我们这个例子中我们使用的是，svnadmin dump命令进行增量的备份，使用方法是：
svnadmin dump project1 --revision 15 --incremental > dumpfile2
上面的命令实现了对修订版本15进行增量的备份，其中的输出文件dumpfile2只保存了修订版本15更改的内容。
为了记录每次提交的结果，我们需要使用一项Subversion的特性--钩子（hook），看看我们的project1目录：
├─project1
│ ├─conf
│ ├─dav
│ ├─db
│ │ ├─revprops
│ │ ├─revs
│ │ └─transactions
│ ├─hooks
│ └─locks |
其中的hooks目录里存放的就是钩子脚本，我们在此处只使用post-commit钩子，这个钩子会在每次提交之后执行，为了实现我们的备份功能，我们在hooks下建立一个文件post-commit.bat，内容如下：
echo off
set SVN_HOME="C:\Program Files\Subversion"
set SVN_ROOT=D:\svnroot
set UNIX_SVN_ROOT=D:/svnroot
set DELTA_BACKUP_SVN_ROOT=D:\svnrootbak\delta
set LOG_FILE=%1\backup.log
echo backup revision %2 >> %LOG_FILE%
for /r %SVN_ROOT% %%I in (.) do if D:/svnroot/%%~nI == %1 %SVN_ROOT%\%%~nI\hooks\deltaBackup.bat %%~nI %2
goto end
:end |
通过这个脚本，可以实现D:\svnroot下的版本库提交时自动增量备份到D:\svnrootbak\delta（确定这个目录存在），其中使用的deltaBackup.bat其实可以放在任何地方，只是对脚本的svnadmin dump的包装，内容如下：
@echo 正在备份版本库%2......
%SVN_HOME%\bin\svnadmin dump %SVN_ROOT%\%1 --incremental --revision %2 >> %DELTA_BACKUP_SVN_ROOT%\%1.dump
@echo 版本库%2成功备份到了%3！
以上两个脚本可以直接拷贝到project2的hooks目录下，不需要修改就可以实现project2的自动备份。
以上的操作已经OK了，现在需要做的是将完全备份和增量备份结合起来，也就是在完全备份后清理增量备份的结果，使之只保存完全备份后的结果。
当果真出现版本库的故障，就要求我们实现版本库的恢复操作了，这是用要使用svnadmin load命令，同时也需要上次的完全备份例如要把上次完全备份backuprepo，和之后的增量备份dumpfile：
svnadmin load backuprepo < dumpfile
最后的结果，可以下载svnroot.rar，将之解压缩到d:\下，然后修改几个bat文件的SVN_HOME就可以使用了。
3, 版本库同步
Subversion 1.4增加了同步机制，可以实现一个版本库同另一个版本库的同步（但好像只是单向的），我们可以用来实现版本库的备份或镜像。
3.1. 对目标库初始化
svnsync init svn://localhost/project2 svn://localhost/project1
其中project2是目标的版本库，而project1是源版本库。其中的目标版本库必须为空，而且必须允许修订版本属性的修改，也就是在目标的版本 库的hooks目录里添加一个文件pre-revprop-change.bat，内容为空即可。
3.2. 同步project2到project1
svnsync sync svn://localhost/project2
这时候你update一下你的project2的一个工作拷贝，就会发现有了project1的所有内容。如果project1又有提交，这时候 project2的版本库无法看到最新的变化，还需要再运行一遍sync操作，这样才能将最新的变化同步。需要注意的是，目标版本库只能做成只读的，如果 目标版本库发生了变更，则无法继续同步了。
3.3. 同步历史属性的修改
因为同步不会更新对历史属性的修改，所以svnsync还有子命令copy-revprops，可以同步某个版本的属性。
3.4. 钩子自动同步
希望在每次提交时同步，则需要在源版本库增加post-commit脚本，内容如下：
echo off
set SVN_HOME="D:\Subversion"
%SVN_HOME%\bin\svnsync sync --non-interactive svn://localhost/project2 |
把以上内容存放为post-commit.bat，然后放到版本库project1下的hooks目录下，这样project1每次提交，都会引起project2的同步。
感谢小余给我们带来的文章。本想根据其中的内容想润色一下，但仔细思考后还是放弃了。每个人的思想和观念都有其独到之处，如果我强行改变，那就是改变原作者的思路了。
原文网址：http://www.cnblogs.com/yice/archive/2008/08/08/1264044.html
内容开始
有个人在交际场合中一言不发，哲学家狄奥佛拉斯塔对他说：“如果你是一个傻瓜，那你的表现是最聪明的；如果你是一个聪明人，那你的表现便是最愚蠢的了。”
我有个朋友自从前年年末开始召集人马进行一个产品的开发，从零开始做这个产品，历时一年多的努力，据说产品在内部也改了5，6个版本。我看过他们的东西， 总体给我的感觉算是不错。从开发到现在也过来一年多的时间，产品也有了初步的 成型系统，而且比较稳定，按照市场运作的模式，应该进入大力推广的阶段。作为开发内部来说，应该进入一个比较平稳的维护和升级阶段，但是从我和朋友聊过之 后，还有与准备离职的开发人员交流之后，发现其中还有不少故事值得说出来给大伙听听。由于我对整个项目的实际进展了解并不多，只是从侧面去观察，所以文章 所简述的观点都是基于个人的看法。在此我还需要强调一点，些这篇文章不是为了批评PM的对与错，只是希望通过我这位朋友身上发生过的事情，折射出一点道路 来，取其精华，也要避免走他曾经走过的弯路。
在项目中需要被提及的任务有三个，资深的开发人员SD（senior developer),项目经理PM（Project Manager),技术型老板TB（Technology Boss).这三个人中我接触比较多的是PM,他也就是我朋友，以前共事的同事，对于他的性格 和做事方法和能力比较了解。SD,我以前的同事，虽然接触不太多，但是对于他的技术和做事态度还是了解。TB呢？说实话，没有见过这个人，只是听其他的人 介绍和从事情中来判断他。
PM是从零开始负责这个产品的开发，从招聘人员，产品的分析，设计都是具体参与在这个项目之中。但是从项目的开发到现在，应该说与他的努力是分不开的。但是本文的主要也是针对于他来写的，因为他是协调TB与SD之间的桥梁，应该说他需要对整个项目进行总体控制。
由于整个公司属于创业型的公司，虽然有另外一家实体企业提供开发资金，但是很多事情还是需要从头开始做，在一开始的时候，PM既要当项目经理，也要当大内 总管，一手抓项目开发，还要一手抓厕所是否有卫生纸等等。这些琐琐碎碎的事情应该说早就超出了一个正规PM的职责范围。但是创业初期，就要求人员要身兼多 职。我想要不是我朋友的好性格和脾气，别人很难能坚持下来。
没有PM的好性格，项目不会有今天的结果，但是也是因为他的好性格，才会使项目出现了比较严重的问题，真可谓成也萧何，败也萧何。如果真正从软件开发项目 经理这个角色来看我这位朋友，我觉得他做的并不到位。我们从项目开发的一些事情来看待这些问题，和欢迎大家讨论一下如果是你换到他的位置，你该怎么处理。
5月的时候,PM从北京回西安来招聘人员(公司原本在西安，今年初的时候搬迁到北京），我帮忙一起面试人员。在招聘过程中他感慨到：“现在招聘不到好的美 工？”听完这句话我觉得非常差异，就听他继续说道：“我希望招聘一个美工，能最快的出图，把老板的项目转变成实际，现在开发中美工的速度跟不上开发的速 度。”
细细品味他的这两句话，我就感觉到他项目有问题，我当时疑惑的问他道：“我觉得很奇怪，美工的速度怎么会跟不上开发的速度？”因为做Web开发的人来说， 一般情况下，UI的开发和程序的开发是前后进行，有了UI之后，开发人员再进行项目的开发，虽然有时候会受一点点影响，但不至于影响道整个开发进度。后来 继续交流过程中才知道，原来美工出图慢的主要原因是老板变化太快，以至于如果老板一个Idea之后，隔天美工出效果，开发人员进行开发，等开之后老板会认 为和他想的存在有差异，需要在次修改，就是这样的循环过程中就出现了“美工缺乏的感慨”。
从与SP的交流中，听到他感慨道，开发中变的太快了，因为TB原先也是做软件出身的，但是由于不是做当前的这个类型的开发，所以对某些问题有时候一知半解 的，而且TB是个追求完美的人，其实由于这套产品对图形的质量的要求非常高，因为图形经过处理后需要打印出来，所以我倒可以理解TB对这方面的完美追求。 但是问题不是处在TB的完美上，而是对于TB的个人强势上面，SP说过，在沟通中TB时时常会抛出这句话：“除了问题你负责啊！”。现在SP也决定从这里 离开，我略微了解了一下，由于各种问题的存在，核心的开发人员都有离开的念头，至少作为PM口中赞不绝口的SP已经离开了。
从事中去分析一下，整个项目开发中可能有不少问题，但是就项目开发的进度把控这块，PM就做的不够到位，至少他没有守住项目的需求变化，老板一个想法，整 个项目进度都会受到影响，而且这些想法有时候时一瞬间的灵感。PM在项目开发过程中，对于如此频繁的需求变化，需要对需求进行汇总，每一个版本的开发尽量 都按照原定的时间安排进行，对于不同的需求变化，在汇总分析之后，阶段性的追加到项目中，以此来降低需求变化的次数已经明确需求的具体内容。对于老板的 Idea倒可以专门安排人员对应他，做原型图后讨论可行性，不要让老板直接接触到开发具体的过程，特别是跨过PM来安排开发人员进行开发工作。
对于TB的强势没有抗住，如果TB的要求合理，也要尽量避免打乱现在的开发计划，维持开发团队的进度稳定。如果TB的要求是天方夜谭，那就要顶住说:"除 了问题我负责。”对于PM来说，在实际过程中需要良好的沟通技巧，不能单纯对上或只向下，PM除了具备有项目过程中的良好项目风险管理和进度预估，掌控能 力外。另外一个角色就是扮演缓冲剂，调节各方面的沟通与交流。千万不要到了项目失败后，自己感慨说我没有功劳还有苦劳，这种阿Q自慰的方式对于希望成为 PM来人来说就是表示你的失败。就像文章开始的那则笑话中所说的那样，在相同的场合，你的角色不同，你做的事情的评定就不一样。
————END————
