svn访问规则
① SVN的用户访问权限设置
在svn中，"复制"其实就是读权限，所以你想限制能读但不能复制，这是做不到的，你给用户读的权限，他就必然可以复制
修改、删除、增加这是写权限，对这些操作可以限制
② 请问SVN可不可以在互联网上连接如果可以连接，需要操作些什么呢，详细说下谢谢啦~
春风沐浴的回答是一个办法，就是把整个库上传到网上免费的SVN空间服务上
如果要自己架设服务器的话，我自己架设过，具体思路是将SVN服务器先架设在局域网上，然后通过路由器的映射将其端口开放给互联网访问。为了解决ADSL线路每次重新连接时随机分配IP地址的问题，我们还需要申请一个免费域名。
下面是我的架设方法，首先你需要具备这些条件：
1、路由器1台，应有端口映射（转发规则-虚拟服务器）功能，最好有内置的花生壳动态DNS功能（否则就需要另外安装花生壳软件）。
2、SVN服务器一台
3、ADSL或其他通往互联网的网络线路
然后需要做以下事情：
1、架设好SVN服务器，保证内网访问畅通。
2、申请免费域名
登录花生壳网站（www.oray.net），免费注册用户，可得到一个免费域名，如“abcde.gicp.net”此域名可长期使用；
3、登录路由器管理页面
通常是访问地址http://192.168.1.1，用户名和密码根据设定输入，各型号路由器的访问方式可能略有不同，可参考说明书进行操作。
4、设置动态域名
如果路由器内置了花生壳动态DNS功能，则可通过路由器直接设置。以TL-WR340G 54M型号的无线路由器为例，在“动态DNS”页面，选择服务提供者为花生壳，输入在花生壳注册的用户名和密码，然后点击登录。
如果路由器没有内置的花生壳动态DNS功能，则需要在花生壳网站下载花生壳客户端软件，安装（可不必安装附带的“向日葵”组件）后使用前面申请的花生壳帐户名和密码进行登录，登录后即可使用免费域名。
5、设置端口映射
仍以TL-WR340G 54M型号的无线路由器为例，在“转发规则-虚拟服务器”页面点击“添加新条目”，在新条目的页面中，设置端口号为项目组SVN服务器的访问端口号，设置IP地址为该路由器分配给项目组SVN服务器的内网IP地址，状态为“生效”，然后保存。
然后你就可以在互联网上通过你申请的免费域名（如“abcde.gicp.net”）代替IP地址来访问SVN服务器了。
③ 如何外网访问SVN。 公司里有SVN。我在家，如何访问请具体描述一下。越详细越好。
那就看你们公司的svn是怎么架的了，要是你们公司有独立的服务器，或者服务器可以对外开发，那你只需要知道地址就行了。
假设是对外放的，你们公司 也有自己的网站在同一个服务器上，那么假设你在公司内网访问时时通过http://192.168.0.1:8808/svn访问的，你们公司的网址是http://www.gongsi.com，那你在家可以通过http://www.gongsi.com:8808/svn访问。
④ 如何做到svn根目录不让访问,但子目录可以访问权限设置
首先，肯定可以实现。
然后，需要了解你的SVN架设环境和权限管理方式。
如果你的SVN服务器是架设在Apache上的，使用的是Apache的用户管理机制，那么你可以在权限文件里这么设置：比如版本库名称是project，这个版本库的所有内容对于部门A（有用户user1～user5）是全部读写权限，对于部门B（有用户user6、user7）仅对其下的fla文件夹有只读权限，但其他文件夹不给任何权限。
[groups]
DepartmentA = uaser1,uaser2,user3,user4,user5
DepartmentB = uaser6,uaser7
[project:/]
* =
@DepartmentA = rw
[project:/fla]
@DepartmentB = r如果按以上设置，部门B访问的时候，你可以告诉他们访问地址直接就是到fla这层文件夹，而不要到project这层文件夹。他们如果用IE访问project这层文件夹，会因没有权限而无法打开，但可以直接访问fla这层。他们如果用TortoiseSVN访问的时候，也是同样只能checkout检出fla这个文件夹。
Subversion 权限简介在 Subversion 的使用当中，存在“认证”、“授权”两个概念。认证，即 authentication，是指用户名与密码的认证。授权，即 authorization ，是指某用户对某个目录是否具备读、写权限的一种审核。这两者配合作用，就组成了 Subversion 的整个帐户管理体系。
⑤ 外网如何访问SVN服务器
在SVN服务器所在的局域网内，使用SVN的内网地址进行https进行访问。正常情况下，在内网是可以正常访问连接使用的。
⑥ SVN使用问题
svn连接不上服务器的原因及解决方法：
1.先在浏览器中访问svn地址，确保svn地址是可以正常访问的。如果可以在浏览器中正常访问，则继续向下进行。
2.检查svn核心
在eclipse菜单中，依次点击，preferences -> Team -> SVN ->SVN接口
如果svn接口的选项是JavaHL(JNI)如图1，则改换成SVNKit(PureJava)，此时再访问svn地址即可。
图1:
注：如果只有一个svn JavaHL(JNI)核心的话，则需要重新安装svn插件了。
⑦ 如何远程访问svn 服务器
方法有很多，最简单的，就是你有一个外网服务器，直接把SVN部署到外网上。但是，我们现在既没有外网服务器，也不能用内网服务器做测试，也就是说，我要用本机，直接部署SVN 在外网访问。也就是，本机就是服务器。
首先你需要有一个自己的域名，然后端口映射SVN到域名上面，这样就可以了。给你们分享一个获取域名和端口映射的软件。我个人用的就是花生壳，一个动态域名解析软件。
⑧ svn有网络限制吗
有。方案一：本地安全策略-->IP安全策略
由于源代码所在服务器操作系统为Windows Server 2008 R2，故本身具有高安全性。可以设置IP安全策略，对特定的服务端口进行控制。此方法对于只允许单个IP、少数IP可以访问有很好效果，但是由于公司总部内网IP段比较多，故设置起来费时费力。因为要单独放行的IP数目过多，它没有放行一个IP段的选项。
方法的设置就不在此赘述了，网上有很多。它的效果非常明显，也很不错，但是由于公司应用条件的特殊要求被我废弃使用此方案。
方案二：采用apache的Allow与Deny
在安装完Visual SVN Server之后，在安装目录下的conf中，肯定能看到一些这样的段落，LoadMole ***
Options FollowSymLinks
AllowOverride None
RewriteEngine on
??
此时只需要在Directory增加Order与Deny规则即可。具体规则可以参见apache的帮助。按照我们公司要求，我只需要如下设置：
Options FollowSymLinks
AllowOverride None
RewriteEngine on
Order Deny,Allow
Deny From All
Allow From 192.168.10 （允许10段访问）
Allow From 192.168.20 （允许20段访问）
Allow From 192.168.30.1 （允许此IP地址访问）
??
好了，设置完成后，只需要重启你的Visual SVN Server服务即可
⑨ SVN的操作说明以及备份策略
2.1 文件检出
安装TortoiseSVN后，SVN会跟Windows的资源管理器完美集成。点击右键，我们可以在菜单栏中选择“SVN检出”选项，输入要检出代码的文件库的URL地址，我们就可以检出该URL地址下的文件库的文件。默认情况下是检出最新版本的代码，如果需要，我们可以通过浏览日志，根据日志来找出想要的版本，然后在“版本”选项中指定相应版本就可以检出相关代码了 。
之后，对于同一个项目的主干开发，我们都在这个检出的代码文件目录下操作，而不是每一次提交或更新都重新检出一次。
2.2 文件添加
我们在本地创建的文件(包括目录)不会受SVN的控制，为了让其接受SVN的控制必须将其添加到文件库中。对于团队其他成员需要的文件，如代码文件、某些模块的.a文件（由于某些需要，该模块代码不公开），我们必须让它们接受SVN的控制，并且保持最新的版本。
2.3 文件删除
当我们需要删除无用的文件(包括目录)时，不能使用Windows的资源管理工具，而必须使用SVN本身的删除文件功能。这样该文件被删除后，其所有修改历史仍然保存在SVN服务器中，以后仍然可以获得该文件的修改历史。
2.4 文件改名
当我们需要对文件(包括目录)进行改名的时，不能使用Windows的资源管理工具，而必须使用SVN本身的文件改名功能。这样该文件被改名后，其改名前的所有修改历史仍然保存在SVN服务器中，保持连续的修改信息。
2.5 文件更新
其他团队成员提交到SVN上的改动不会自动更新到你的本地拷贝中来，我们需要通过更新文件操作来获取其他成员对项目文件所做的修改。SVN更新文件操作会把文件库里的文件与本地文件进行合并，从而达到了同时保留其他成员的修改及本地的修改的目的。如果无法自动合并则会发生冲突，需要使用文件比较工具进行手工合并，合并完成后才能提交已解决冲突的文件。冲突的详细解决方法见第三章——冲突解决。
在团队开发时，更新是一件很重要的工作，可以保持团队成员之间的工作内容一致，因此要注意经常更新自己的工作拷贝，以保证自己能够获得最新的修改内容。
2.6 改动提交
我们对文件(包括目录)所做的一切改动，包括添加、删除、修改文件都必须提交到SVN服务器文件库中才能正式生效，之后团队的其他成员才可以获取你所作的修改。
提交是很重要的一项操作，要求做到：
提交代码之前一定要保证修改后的代码能编译通过，不能提交编译不通过的代码。
比较修改前及修改后的代码，把调试信息或其他不相关的信息去掉，再次确保提交的代码是正确的并且提交的是需要提交的文件。
不要等到修改了很多代码才提交，而是相关小功能完成时就应该提交一次。这样以后发现问题时就很容易撤销有问题的代码——因为撤销只能针对一次提交，所以在一次提交里涉及过多的功能是不推荐的。
提交时必须填写log信息，说明这次提交增加了什么功能或者修正了什么bug。这些信息有助于自己和其他团队成员了解整个项目的历史。当出现问题时也方便定位到对应的版本代码，所以log信息必须足够详细。
事务性提交。也就是说提交要么成功，要么全部失败——即提交出现错误时会自动回滚，实际上没有提交任何东西。出现错误时，解决错误，再次提交上次提交的全部内容即可。
3. 冲突解决
冲突的解决是我们使用SVN过程中的一个棘手问题，所以独立一节来谈论。
3.1 冲突的产生
冲突发生在多个成员同时对同一个文件进行修改的情形下。即当有其他成员已经提交了修改，而自己在本地拷贝中也对该文件进行了修改，而且修改的是同一个地方，那么在进行本地文件的更新时，SVN会不知道该选择那个修改（SVN上的修改还是本地的修改）来进行合并，所以冲突就产生了。
举例说，假如受SVN控制的文件Day.txt在SVN服务器上的当前内容如下：
图表 3 Day.txt文件在本地的修改
我们可以看到，在文本的第一行，SVN上及本地都做了修改。这样当在本地进行更新（提交之前必须先更新），SVN合并时就不知道monday后面到底该是work还是sleep，所以冲突就产生了。
而第三、五行是各自进行了修改，并没有冲突，所以这两行可以顺利合并，合并后可以看到所有人所做的修改。
3.2 冲突的解决
冲突发生后，SVN会在本地保存该文件的不同修改版本，见下图蓝色图标：
图表 4 Day.txt文件的不同版本
Day.txt.r35是版本35的Day.txt文件（本地拷贝最新版本）
Day.txt.r37是版本37的Day.txt文件（SVN上最新版本）
Day.txt.mine的是本地修改后的Day.txt文件
Day.txt文件中包含了合并后的内容
3.2.1 简单冲突解决
对于简单的内容冲突，我们可以直接在合并后的文件上修改。在上例中，我们打开Day.txt文件，可以看到SVN合并后的内容：
图表 5 Day.txt合并后内容
我们看到没有冲突的修改：(play basketball)及（meeting）顺利地合并了，而冲突的部分出现了一些标记。其中标记
<<<<<<< .mine
=======
之间包含的是本地修改的冲突部分的内容，即monday(work)。而标记
=======
>>>>>>> .r37
之间包含的是版本37（SVN上最新版本）该部分内容，即monday(sleep)。
不失一般性，假如我们现在要保留的内容是monday(work)，那么我们只要把标记及monday(sleep)部分内容去掉即可：
图表 6 Day.txt解决冲突后内容
确保修改正确后，把Day.txt文件设置为“已解决的”。
图表 7 Day.txt标记为已解决
之后，后缀为mine,r35,r37文件全部消失，仅保留已解决冲突的Day.txt文件，提交到SVN即可。
3.2.2 复杂冲突解决
对于文件内容复杂的文件，上述的解决方法容易漏掉一些要修改的部分，解决起来也耗时耗力。这时要通过SVN提供的工具来解决。
选择SVN功能“编辑冲突”，打开冲突编辑工具:
图表 8 冲突编辑工具
上半部分的两个内容栏分别显示的是版本37的内容及本地修改的内容。
下半部分的内容栏显示的是合并后的内容。
每个内容栏左边的标记清楚地标识了该文件做了那些修改。
文件冲突的部分用红色显眼地表示了出来。在合并栏，点击冲突部分，点击右键，我们可以选择用哪个内容（SVN上最新内容或者本地修改内容）来解决冲突部分，也可以选择两个内容都使用，同时选择它们出现的先后顺序。
逐一解决各个冲突。确保所有冲突都解决后，保存文件，并标记为“已解决”的，退出该工具即完成冲突的解决。
4. 加锁策略
事实上，解决冲突还有一种方法，那就是“严格加锁”。
“严格加锁”要求在编辑文件之前必须先对文件加锁，然后才能进行编辑。此时团队其他成员不能对该文件进行编辑，即保证了同一时刻只有一个人在编辑该文件，因此避免了冲突的出现。
那么，什么类型的文件我们应该采取“严格加锁”呢？
Excel、图片等不可合并的文件，我们必须对其“严格加锁”。“严格加锁”的文件都标记为“可读”的，即不可编辑。要编辑这些“严格加锁”的文件，必须先对其加锁，加锁后文件更改为“可读可写”。编辑完这类文件后要第一时间提交。提交完成时，SVN会自动解开任何你拥有的锁 。
文本文件，比如程序代码，SVN通常可以为我们合并改动，无须“严格加锁”。对于一些大家都频繁改动的重要源代码文件，可能会引起大量冲突，我们也不推荐“严格加锁”，因为加锁会导致大家持续得走来走去去询问加锁情况。正确做法是把文件分成数个逻辑单元，大家都修改各自的单元，减少合并时的冲突。
5. 标签&分支
一个项目最初存放的目录我们称之为主干(trunk)。下面我们讨论除了主干之外其他存放项目的目录——标签(tag)和分支(branch)。
5.1 标签（tag）
版本号可以区分多次的代码修改，我们可以使用版本号来检出需要的代码，但对于重要版本的代码，如第三版发布代码，我们不希望记住r37这样的数字。这时，我们就可以通过创建标签来对SVN中这个发布版本的文件的这个时刻的状态创建一个“快照”，以后就可以通过这个标签名字来检出第三发布版本的代码。
标签其实是当前项目文件的简单拷贝，保存在标签所在的目录下。创建标签也是挺简单的，不过要注意：
标签的名字一定要有描述性，可以仅凭名字就知道为什么要创建标签。
不能过多地使用标签，只有在重要时刻或者发布版本时才可以创建标签。
标签是项目文件在某个时刻的状态，不能对其进行修改 。
5.2 分支（branch）
分支跟标签一样，也是当前项目文件的简单拷贝，保存在分支所在的目录下。
分支跟标签的根本区别在于，标签不能对其进行修改，而分支就是为了某种目的的修改而建立的。在检出代码时检出指定分支即可，分支的操作跟主干上的操作完全相同。
5.2.1 何时创建
遇到下述情况，我们可以通过创建分支来解决问题：
发布分支
当我们快要发布一个版本了，一个开发小团队要为这次发布做好准备，比如说修改一些收尾的bug。这时他们需要的是项目的稳定性，而同时我们还有其他团队要开发预计下次发布才会添加进去的功能，显然他们不能在同一份代码上工作，因此我们需要从主干中建立出一个发布分支，发布团队都从这个发布分支检出及提交代码。当程序被发布之后，这个分支依然是活动的。这样，如果客户报告了一些bug，团队会在这个发布分支中修正它们并视情况合并到主干中去。
试验分支
当我们需要对项目做大范围的改动，并且这改动对系统的其余部分有深远的影响，而我们又不能保证这次改动一定能成功的时候就可以建立试验分支。如果试验失败了，可以废弃这个分支；成功了我们只要把分支的改动合并到主干代码中去就可以了。
其他情况，我们不建议创建分支，更不推荐在分支上创建分支，因为分支过多，合并时的冲突将会是一种难于解决的灾难。
5.2.2 合并分支
我们在分支上所修正的bug很可能在主干上或者其他分支上也存在，因为它们往往来自同一份代码，所以我们在分支上所做的改动有必要合并到主干或者其他分支中去。
对于简单的bug，一次提交就能解决问题的，那么我们只要记住提交新版本号，然后使用新版本号把改动合并到其他的受影响的主干及分支中去就可以了。
对于复杂的bug，可能需要多个开发者花几天的时间提交多次才能修好。这时光用版本号来记住修改的内容就有点勉为其难了。因此，我们可以使用标签来标记我们修正过程的开始和结束，然后使用这些标签帮助我们把修正的代码合并到主干和其他分支中去。整个过程如下：
① 给分支打个标签，标记bug修改开始。
② 测试重现bug，修正代码让新测试通过。
③ 提交你的改动到SVN上。
④ 重复步骤2、3，直到确定bug已经修正。
⑤ 再给分支打个标签，标记bug修正结束。
⑥ 使用两个标签来把修正的代码合并到所有其他受影响的主干和分支上。
6. 注意事项
经常更新
由于文件可能有多个人修改，应该经常更新你的工作拷贝中的文件，这样能降低发生冲突的可能性。
测试提交
提交前先在本地进行测试。不允许将有错误的文件提交到SVN服务器上。
填写备注
提交时一定要写备注：备注有助于其他人（包括三个月后的你自己）理解你对文件所做的修改。
整体提交
提交文件时注意要提交一项改动所对应的所有文件，不要一次提交一个文件或者一次提交修改了很多功能的一堆文件。
发布标签
对于每一个发布的版本都要建立标签：当用户告诉你发生某个问题时，你可以迅速地追踪到问题是在哪个版本引入的 。
附：测试自动化小组SVN使用指导原则
1. Project的构建
Project在SVN服务器上的目录架构如下：
SVN上的项目文件：
1. 必须保证Trunk上的代码是最新的！定期对Trunk上的代码进行更新，各小组可根据各自实际情况自己把握
2. Tag是根据项目需要所打的标签，每一个发布的版本都要打Tag，主要是方便有需要时可以直接根据Tag返回到之前的状态，以便于分析、测试；Tag中必须包含相应的release文件及当时编译或发布时的源代码，必须有相关的文档注明项目背景、发布情况等。
3. Branch文件夹可以用作备份用，可以用个人名字命名文件夹；此外，Branch分支主要用来进行短暂或者探索性的开发使用，最终的软件版本必须更新、合并到Trunk主干上。
4. 关于同一项目组开发环境的建议：同一项目组成员的开发环境最好一致，软件安装路径和Project文件存放路径最好一致。
2. 版本号
关于版本号命名规则：主版本号.子版本号.修正版本号
1. 项目初版本时，版本号为0.1.0；
2. 当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变，修正版本号加 1；
3. 当项目在原有的基础上增加了部分功能时，主版本号不变，子版本号加 1，修正版本号复位为 0；
4. 当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，主版本号加 1，子版本号和修正版本号复位为0；
5. 编译版本号一般是编译器在编译过程中自动生成的，我们只定义其格式，如果编译器不能自动生成，人手添加，数值代表为当前的系统时间。
例子：V1.0.1 Build090305 Rel111123
其它版本使用规则：
1. α（alphal）内部测试版
此版本表示该软件仅仅是一个初步完成品，只在组内内部交流，该版本软件的 bug 较多，限内部测试使用。
例子：V0.1.1 Build090305 alphal1
2. β（beta）外部测试版
该版本相对于α版已有了很大的改进，经过组内的测试，消除了严重的错误，但还是存在着一些缺陷，需要经过大规模测试来进一步消除。
例子：V0.1.2 Build090305 beta1
3. demo 演示版
仅限评审或讲解时做介绍使用。
例子：V0.1.3 Build090305 demo1
4. release 最终版
该版本意味“最终释放版”，在出了一系列的测试版之后，终归会有一个正式版本，一般情况下，release不会以单词形式出现在软件封面上，取而代之的是符号 (Rel) 。release版本发布时，必须将待发布的软件和相应版本更新记录打包在一起发出。
例子：V1.0.1 Build090305 Rel111123
3. 权限限制
如果项目本身需要对项目组成员作不同的权限控制，可以考虑维护两个工程：一个工程里面有相应的源文件，一个则只有编译后的文件。
4. 模块的版本维护
1. 文件一般不需要版本，但要有详细的更新历史记录；
2. 模块可以以版本来维护，具体可以不同的文件夹区分。
⑩ SVN怎么让每个人访问不同文件
svn权限控制是到文件夹级别的，不是到文件级别，因此你需要首先将文件夹结构设置好，每个人要看的文件分别放在不同的文件夹中，比如根目录是aaa，下面每个人对应的目录分别是a1、a2、a3、a4
然后在权限文件里先设定对根目录所有人有读取权限“*
=
r”，在每个人对应的目录里设定两条“*
=
”(所有人无任何权限)和“username
=
r”（对应的用户有读取权限）
这样就可以实现每个人只能读取自己的文件夹
按你所说的，你得先把test1、test2分别放到两个文件夹中，比如根目录aaa，a1文件夹中放test1文件，a2文件夹中放test2文件，那么这个权限文件就这么写：
[aaa:/]
*
=
r
[aaa:/a1]
*
=
user1
=
r
[aaa:/a2]
*
=
user2
=
r
这样user1、user2检出aaa这个文件夹的时候，user1检出的aaa中只有a1这个文件夹，user2检出的aaa中只有a2这个文件夹
当然了，如果你要的是读写权限的话，就把上面的r换成rw，另外还可以把aaa下面的“*
=
r”换成“user1
=r”和“user2
=r”这两句
如果用户比较多，想控制的更复杂的话，可以在权限文件中用group设置用户组，按组来控制权限