TortoiseSVN应用-->基础概念

1、基础操作概念

Checkout(检出)：

在新建文件夹中，获取版本库中的任意一个版本。

SVN会将版本库中的选定版本复制一份到当前文件夹，此文件夹被称为工作副本。

于此同时，SVN会建立一个.svn隐藏文件，用于对工作副本作修改记录。

注意：将要进行文件或文件夹的增加，删除，移动等操作时，尽量使用SVN自带功能操作，避免异常！

Update(更新):

在多人进行同一项目时，需要将他人做的修改更新到当前工作副本中以保持同步。

当多人在同时修改同一文件时，执行更新很可能会发生冲突，此时最好共同协商解决冲突。

Commit(提交):

将工作副本所做修改提交至版本库，版本库会更新已修改文件的版本号。

当同时有多人对同一版本修改时，直接提交会失败，此时需要更新他人更改然后再提交。

Create repository(创建版本库)：

在当前空文件夹创建某一项目的版本库，禁止对版本库手工修改!

可以初始选择创建以下3个目录：

trunk:项目主干

当前开发的项目主体

branches:项目分支

当项目主干进行下一大版本开发时，发现上一大版本具有BUG，所以就需要为其创建分支。

很可能主干项目同样需要某些对应修改，所以需要在合适的时候进行合并(merge)。

同理，主干做的修改很可能会分支也有用，所以也可以进行更新。

tags:项目标记

一般用来对项目某个版本进行一次冻结，这个文件夹只应该用来读取。

若需要对某个冻结版本做测试，正确操作应该是为其建立工作副本，并且工作副本的任何修改不提交。

 

对于以上3个文件夹的说明，可以用一个比喻：

trunk就是我们最开始种的一棵树，这棵树有很多枝叶(功能)。

branches是我们根据trunk复制过来的另外一棵树，但是这两个树的某些枝叶是一模一样的(相同功能部分代码相互更新)，

也有某些枝叶是不一样的(不同功能部分分别发展)。

tags就是一个相册，每张相片分别记录下每棵树最稳定的样子。

 

网上还有对于三个文件夹的另外一种用途解释：

trunk是稳定版，branches是开发版，待开发版稳定后再更新到trunk中去，

tags则为稳定发布版的备份。

Revert（还原）：

可以将修改过的文件还原到未作修改的状态。若文件已经删除或者改名，

那么需要在上一层文件夹上执行还原操作。

Cleanup(清理)：

当异常情况下，使用此命令清理.svn文件夹，可以解决问题。

branch/tag(分支/标记):

TortoiseSVN创建分支标记的原理和UNIX的硬链接是一个道理。

创建分支和标记时，SVN会直接将动作更新到版本库，而当前的工作副本是没有改变的。

切记需要为分支或标记创建新文件夹！

switch(切换):

将当前工作副本切换为分支/主干/标记等。

需要注意的是，当工作副已经修改过后，切换动作会智能合并。

为了避免这个怪异的效果，最好在切换前提交或者还原。

 merge(合并):

用于主干和分支的相互同步更新。

为了有退回的余地，在执行合并前，务必保证当前工作副本已经提交!

 

合并概念及注意事项参考链接:

http://svnbook.red-bean.com/en/1.8/svn.branchmerge.html

lock(锁)：

锁的概念和操作系统中的互斥锁很相近，获得锁的工作副本才能对文件操作，其他工作副本必须等待释放锁以后才能获得锁操作。

注意：一般锁仅仅用于单个文件，不建议用于文件夹。若用于文件夹，则其他开发者就无法对文件夹操作了，会被鄙视的.......

patch(补丁):

和Linux下的patch/diff命令很相似

blame(追溯)：

将文件的修改历史，修改作者等信息列出来，精确到行。

export(导出)：

生成一个没有.svn文件的工作副本。

Relocate(重定向版本库):

当版本库被移动或路径更改后，使用此命令将工作副本重新与库关联。

2、常规操作方式

为项目创建版本库：

对于一个项目，是由好几个部分组成，比如代码，机械，电路等。

所以需要在前期为项目规划好几个部分，创建相应文件夹，且包含trunk、branches、tags。

对于相对比较复杂的代码，还应该进一步细分下去。

当然，在后期工作中，可以随时调整这些文件夹的结构。

备份版本库:

复制->粘贴，简单粗暴。

修改工作副本版本:

在当前工作副本，需要恢复到以前的一个版本。若单纯的在日志对话框中复原一个版本，那么SVN会

智能合并当前工作副本的修改，最终结果会比较怪异。正确的操作方式是先在工作副本使用还原操作，

撤销对于当前版本修改，然后再复原到一个版本。

删除/移动/重命名：

在删除/移动/重命名 等操作后，必须提交一次，这是为了让版本库目录树时刻保持着与工作副本一致。

避免执行更新操作后，会出现文件结构混乱的情况。