Svn目录结构：trunk；tags；branches
在Svn世界中，目录没有特殊的含义（都是人为赋予的），也就是说，所谓的目录结构并不是必须的，而是一种约定俗成的，大家都这么使用的“事实上的标准”。
你不这么构造目录结构，也完全可以。
但是出于各方面考虑，还是建议遵从一般的约定来构造Svn目录的。
假设有一个repo为：svn://ip:port/，其中有一个项目是myproj，那么这个项目的url为：
svn://ip:port/myproj
标准地来说，在myproj目录下应该至少有三个目录：trunk，tags以及branches。
svn://ip:port/myproj/trunk
svn://ip:port/myproj/tags
svn://ip:port/myproj/branchestrunk为主开发目录，branches为分支开发目录，tags为tag存档目录（不允许修改）。
trunk：
是svn开发的主干，日常开发都是从这里出库最新代码，然后合并到主干中。
tags：
milestone。是各种具有一定意义的，阶段性的发布版，比如有个1.0版本，可以打一个tag，有个2.0版本，再打一个tag，等等。
branches：
trunk是主干，那么branches相对来说就是分支了。例如某些版本还需要继续维护和开发，可以放在branches中（注：tags中通常不再对其修改）；例如某些版本是为了某些客户专门修改过的，也可以放置在branches中。
通常来说tags目录是只读的，可以使用svn的authz来对其进行限制。
tags的作用：
在经过了一段时间的开发后，项目到达了一个里程碑阶段，你可能想记录这一阶段的代码的状态，那么你就需要给代码打上标签。
branches的作用可以用下面例子来解释：
John突然有个想法，跟原先的设计不太一致，可能是功能的添加或者日志格式的改进等等，总而言之，这个想法可能需要花一段时间来完成，而这个过程中，John的一些操作可能会影响Sally的工作，John从现有的状态单独出一个project的话，又不能及时得到Sally对已有代码做的修正，而且独立出来的话，John的尝试成功时，跟原来的合并也存在困难。这时最好的实践方法是使用branches。John建立一个自己的branch，然后在里面实验，必要的时候从Sally的trunk里取得更新，或者将自己的阶段成果汇集到trunk中。
branches还可以：
有个客户想要定制化的产品，但是我们并不想修改svn中trunk中的代码，因为不能因为一个客户影响了整个项目的日常开发呀。
于是我可以建个branch，然后从trunk中copy一份到branch，继而进行客户定制化开发。
当发现阶段性的tag存在一个bug，想要修复，我可以把它branch出来，单独修复bug，完事之后再打一个tag，标识这个是修复好的版本，然后可以将这个修复merge到trunk。
我们公司当前的结构基本是：
还是那句话，svn不强制要求如何如何规定目录结构，怎么用还是在于个人。
参考来源：
1.http://www.cnblogs.com/newstar/archive/2011/01/04/svn.html
2.http://www.jianshu.com/p/15b60bdfa856
3.http://blog.csdn.net/pttaag/article/details/8076210