Subversion使用过程介绍
参考资料：http://www.subversion.org.cn/index.php?option=com_content&task=view&id=56&Itemid=9，与
《Widnows下SVN使用教程》
一、服务器端的安装
、
二、客户端的安装
三、建立版本库（repository）
1、图形化方式
注：嵌入的数据库((DBD，Berkeley database)
定义格式的纯文件(FSFS，Native filesystem)
两者比较，见http://doc.iusesvn.com/show-21-1.html
在repo1目录下新增很多内容：
2、命令方式
在repo2下也新增一些文件：
四、配置用户和权限
修改repo1（上一步设置的repository）下conf目录下的svnserve.conf文件，去掉
# password-db = passwd
前的#
再打开passwd文件，去掉
[users]
# harry = harryssecret
# sally = sallyssecret
前的#
五、运行独立服务器
在任意目录下运行：
svnserve -d -r E:"02_study"06_subversion"svndemo"repo1 我们的服务器程序就已经启动了。
注意不要关闭命令行窗口，关闭窗口也会把svnserve停止。
六、初始化导入
在将要导入的目录（事先准备了项目例子目录proj_expl，下面只有一个readme.txt文件）上右击
注：localhost可以是运行svnserve所在的IP
用户名：harry
密码：harryssecret
在repo1下的db目录下，多了东东
注：Import的那层文件夹不导入，导入的是import那一层下的文件与目录。
七、基本客户端操作
1、取出版本库到一个工作拷贝(import)
来到任意空目录下，运行右键->Checkout
在空目录work_dir1下多了文件readme.txt
2、修改
3、添加文件(Add)
新加的文件：
4、检查更新(check for modifications)
5、检入（commit）
6、Repo-browser查看
7、diff
8、revert
9、多人修改相同文件后的问题
Update后
在文字前面的“+”号上右击选择相应的操作
10、Branch/tag与switch
在工作副本目录下的某个文件或目录上，右击，选择Branch/tag
在To URL里输入branch的创建位置
注：在OK左边有选项“switch working copy to new branch/tag”
在repository browser里刷新后可以看到
在某个工作副本上右击，选择switch
注：在To URL里输入branch路径
查看此工作副本目录下某文件的revision graph：
在各branch里修改后，查看revision graph：
11、merge
（1）、merge操作也就是往需要merge的文档中写的过程，所以merge之后还要进行commit操作将结果提交到服务器。
（2）、merge有个from与to的区别：
可见修改的是from的文件――from的文件变成了to的内容。
（3）、没有branch"tag关系的文件不能merge。
（4）、没有找到记录merge操作的地方――show log、revision graph里都没有。
12、get lock与release lock
只有lock的那个工作副本目录下可改（即不允许他人使用），其他的工作副本里改后commit时，提示：
在进行get lock的工作副本上再进行release lock（在哪get clock就在哪release lock，否则无效），就可以正常地commit了。
八、修改设置
1、控制文件夹使用“_SVN”以便支持ASP.NET项目。
要重启才生效
2、设置忽略
3、配置强制注释
在本地工作副本上右击
删除work_dir1后
重建了另一个工作副本后强制注释配置没问题：
Commit时输入五个字符前“OK”是灰显的
注：对别的成员也有效，但对别的svn客户端无效？？？――未试验
2008-4-28
束丽华
九、svn命令
1、checkout命令
2、添加文件
先把上传的文件放在相应的本地工作副本中
3、commit
4、更新
5、查看log
2008-7-4
十、SVN的备份与恢复
Repository Backup
Despite numerous advances in technology since the birth of the modern computer, one thing unfortunately rings true with crystalline clarity—sometimes, things go very, very awry. Power outages, network connectivity dropouts, corrupt RAM and crashed hard drives are but a taste of the evil that Fate is poised to unleash on even the most conscientious administrator. And so we arrive at a very important topic—how to make backup copies of your repository data.
There are two types of backup methods available for Subversion repository administrators—full and incremental. A full backup of the repository involves squirreling away in one sweeping action all the information required to fully reconstruct that repository in the event of a catastrophe. Usually, it means, quite literally, the duplication of the entire repository directory (which includes either a Berkeley DB or FSFS environment). Incremental backups are lesser things, backups of only the portion of the repository data that has changed since the previous backup.
As far as full backups go, the naive approach might seem like a sane one, but unless you temporarily disable all other access to your repository, simply doing a recursive directory copy runs the risk of generating a faulty backup. In the case of Berkeley DB, the documentation describes a certain order in which database files can be copied that will guarantee a valid backup copy. A similar ordering exists for FSFS data. But you don't have to implement these algorithms yourself, because the Subversion development team has already done so. The svnadmin hotcopy command takes care of the minutia involved in making a hot backup of your repository. And its invocation is as trivial as Unix's cp or Windows' copy operations:
$ svnadmin hotcopy /var/svn/repos /var/svn/repos-backup
The resulting backup is a fully functional Subversion repository, able to be dropped in as a replacement for your live repository should something go horribly wrong.
When making copies of a Berkeley DB repository, you can even instruct svnadmin hotcopy to purge any unused Berkeley DB logfiles (see the section called “Purging unused Berkeley DB logfiles”) from the original repository upon completion of the copy. Simply provide the --clean-logs option on the command-line.
$ svnadmin hotcopy --clean-logs /var/svn/bdb-repos /var/svn/bdb-repos-backup
Additional tooling around this command is available, too. The tools/backup/ directory of the Subversion source distribution holds the hot-backup.py script. This script adds a bit of backup management atop svnadmin hotcopy, allowing you to keep only the most recent configured number of backups of each repository. It will automatically manage the names of the backed-up repository directories to avoid collisions with previous backups, and will “rotate off” older backups, deleting them so only the most recent ones remain. Even if you also have an incremental backup, you might want to run this program on a regular basis. For example, you might consider using hot-backup.py from a program scheduler (such as cron on Unix systems) which will cause it to run nightly (or at whatever granularity of Time you deem safe).
Some administrators use a different backup mechanism built around generating and storing repository dump data. We described in the section called “Migrating Repository Data Elsewhere” how to use svnadmin dump --incremental to perform an incremental backup of a given revision or range of revisions. And of course, there is a full backup variation of this achieved by omitting the --incremental option to that command. There is some value in these methods, in that the format of your backed-up information is flexible—it's not tied to a particular platform, versioned filesystem type, or release of Subversion or Berkeley DB. But that flexibility comes at a cost, namely that restoring that data can take a long time—longer with each new revision committed to your repository. Also, as is the case with so many of the various backup methods, revision property changes made to already-backed-up revisions won't get picked up by a non-overlapping, incremental dump generation. For these reasons, we recommend against relying solely on dump-based backup approaches.
As you can see, each of the various backup types and methods has its advantages and disadvantages. The easiest is by far the full hot backup, which will always result in a perfect working replica of your repository. Should something bad happen to your live repository, you can restore from the backup with a simple recursive directory copy. Unfortunately, if you are maintaining multiple backups of your repository, these full copies will each eat up just as much disk space as your live repository. Incremental backups, by contrast, tend to be quicker to generate and smaller to store. But the restoration process can be a pain, often involving applying multiple incremental backups. And other methods have their own peculiarities. Administrators need to find the balance between the cost of making the backup and the cost of restoring it.
The svnsync program (see the section called “Repository Replication”) actually provides a rather handy middle-ground approach. If you are regularly synchronizing a read-only mirror with your main repository, then in a pinch, your read-only mirror is probably a good candidate for replacing that main repository if it falls over. The primary disadvantage of this method is that only the versioned repository data gets synchronized—repository configuration files, user-specified repository path locks, and other items which might live in the physical repository directory but not inside the repository's virtual versioned filesystem are not handled by svnsync.
In any backup scenario, repository administrators need to be aware of how modifications to unversioned revision properties affect their backups. Since these changes do not themselves generate new revisions, they will not trigger post-commit hooks, and may not even trigger the pre-revprop-change and post-revprop-change hooks. [39] And since you can change revision properties without respect to chronological order—you can change any revision's properties at any time—an incremental backup of the latest few revisions might not catch a property modification to a revision that was included as part of a previous backup.
Generally speaking, only the truly paranoid would need to backup their entire repository, say, every time a commit occurred. However, assuming that a given repository has some other redundancy mechanism in place with relatively fine granularity (like per-commit emails or incremental dumps), a hot backup of the database might be something that a repository administrator would want to include as part of a system-wide nightly backup. It's your data—protect it as much as you'd like.
Often, the best approach to repository backups is a diversified one which leverages combinations of the methods described here. The Subversion developers, for example, back up the Subversion source code repository nightly using hot-backup.py and an offsite rsync of those full backups; keep multiple archives of all the commit and property change notification emails; and have repository mirrors maintained by various volunteers using svnsync. Your solution might be similar, but should be catered to your needs and that delicate balance of convenience with paranoia. And whatever you do, validate your backups from time to time—what good is a spare tire that has a hole in it? While all of this might not save your hardware from the iron fist of Fate, [40] it should certainly help you recover from those trying times.
2008-10-13
重命名项目目录：将第一层目录改名后，修改目录下内容后commit时未出现问题
但根目录上提示有改动，commit时
选中后OK
提交成功
修改文档后再commit，出错：
Update根目录
日志中显示delete
2008-10-14
想到用branch来恢复历史的版本――删除之前的版本
提示：
再进行switch操作
