SVN目录机构
SVN是典型的目录结构式的文件管理
SVN
|
|———— 产品
| |___ trunk
| |___ branchs
| |___ tgs
|—— 研发
| |___ 服务端
| | |___ trunk
| | |___ branchs
| | |___ tgs
| |
| |___ 移动端
| | |___ trunk
| | |___ branchs
| | |___ tgs
| |
| |___ Web端
| |
| |___ ...
|
|—— ...
|
一个公司的SVN目录可能很多，而且可能都不大一样，但是一样的是都是目录结构。
主目录，主开发目录，各自开发都是基于这个目录进行开发的，但是不是在这条主目录上开发。
分支开发目录，开发时候基于trunk目录检出的一个开发分支目录，当开发完毕某个功能后合并到trunk去。
为tag存档目录，每次trunk上任务开发整合完毕后进行发布版本，这个里面存储每次发布的版本代码。这个目录下只做存储，不做修改。
题外话
理想的SVN目录管理结构如上所展示的，分目录去管理，这也是可以实现的。
但是很多公司可能并不这样去做，一是可能觉得这样太麻烦，的确SVN比起git对分支的操作挺麻烦的。
每个公司对SVN的管理有不同，文件目录也就不同，可能很多公司的SVN根本就不分什么trunk、tags、branchs，直接在目录下面进行操作和管理。直接将版本保存在一个文件夹下也是未尝不可的，你说人家一个产品，只要保存好每个版本的原型就好了，还要做什么branchs、tags分支，那得多麻烦，只要便于管理，当然越简单越好。
但是我没有试如果好多人同时开发的情况下，如果同时去操作某个目录下的某个文件的话会怎么样，肯定是会冲突。
检出分支
从已有的分支检出一个新的分支
svn copy <https://svn.xxx.com:8443/svn/xxx/xxx/xxx/> \
<https://svn.xxx.com:8443/svn/xxx/xxx/xxx/> \
-m "描述"
