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操作
