]]>当前用 SVN 的原因是公司内还有好多非技术类的同事会用到版本控制系统来存取文件。
对他们来说，SVN 已经是他们能掌握的技术天花板了。
目前想搭建新的 SVN 服务器系统，逐步把老的迁移过去。
新 SVN 服务器还是需要容易操作，有稳定并容易操作的界面让有权限的员工增删仓库，修改权限啥的。
但现在的遇到一些问题。
Visual SVN Server 新版，免费版限制了使用人数。
所以现在想知道除了使用老版本的 Visual SVN Server ，或者付费。还有其他途径搭建一套稳定好维护的 SVN 服务器吗？ ]]>
svn: E170013: Unable to connect to a repository at URL 'https://项目地址'
svn: E120171: 执行上下文错误: An error occurred during SSL communication
搜遍全网。分别有这两个回答情况一致
https://superuser.com/questions/1473219/subversion-error-svn-e120171-error-running-context-an-error-occurred-during
https://stackoverflow.com/questions/72201289/cant-do-svn-checkout-because-of-tls-error
都是说调整 openssl 的 TSL 配置。 调了，没效果
后查 openssl 发现 mac 自带一个 LibreSSL ，更改环境变量换为 brew 安装的 openssl 后
还是没效果
CSDN 上找到一个 9 月份国内的分享，他分享了一个单体 SVN 放在/usr/local/bin 下的
打命令可以做一下操作，但是每次都要输入账号密码，且不能在 idea 中使用。
后继续尝试 apache svn 官网下载了好几个版本，编译，安装，均无效果。
其中有部分版本会只报
svn: E170013 的错误
不会报 svn: E120171
最后在逛本区刚好有人在问 svn 客户端那个好 他说他用的 smartsvn
我就下载了一下，这个软件就可以正常使用。
从早上折腾到现在，一直搞不定，
系统重装了几次，14 不行 12 也不行。
电脑是 21 款 M1 MacBookpro
求大神给上一课。
-
SVNAdmin2 是一款通过图形界面管理服务端 SVN 的 web 程序。
-
正常情况下配置 SVN 仓库的人员权限需要登录到服务器手动修改 authz 和 passwd 两个文件，当仓库结构和人员权限上了规模后，手动管理就变的非常容易出错，本系统能够识别人员和权限并提供管理和拓展功能。
-
SVNAdmin2 支持SVN 协议检出、HTTP 协议检出，并且支持两种协议之间互相切换，支持 docker 部署或源码部署。
-
SVNAdmin2 支持进行LDAP 的接入，进而达到使用原有的人员架构和分组规则的目的。
-
SVNAdmin2 第一个版本（ 20 年初）被开发用来个人管理 SVN 仓库使用，无意中开源后发现用户渐多，于是开始专门维护迭代。
-
问题求助、功能建议、更新计划、SVN 技术讨论，可加 QQ 群：633108141
-
项目演示地址： http://svnadmin.witersen.com (管理人员 /admin/admin)
-
系统截图
]]>目前找到的，都是收费的 ]]>
.svn a.txt b.txt dir/c.txt dir/folder/d.txt dir/folder/e.txt 我想把 dir 目录下的 folder 在提交时忽略掉，根据教程，有此设置：svn propedit svn:ignore .
写入：
*.log dir/folder 提交全部文件时：svn add --force .
依然会提交 dir/folder 下的文件，请问该如何设置？
]]>svn 拉下来就是一个工作目录了。（ PHP 的，就是网站的根目录，tp3.2 ）。
自己比较习惯 git，不太熟悉 svn，可能有些地方理解有问题，见谅。
顺便吐槽一下，像这样的情况遇到不少了，感觉好多人把 svn 当作高级版的 ftp 。。。呃
]]>右键项目 -> Subversion -> Show History 时，一直加载中，如图：
https://i.loli.net/2020/04/09/Gwxkd5YMpVERqP7.png
等了几分钟都没反应，此时 idea 会未响应。
可以正常使用 update 、commit，检查了 idea 的 proxy 代理也未开启，可以排除网络问题
网上搜索了一遍，似乎此类问题很少，问了同事也有这个问题，不知道是啥原因导致的。
]]>[Thu Oct 17 22:53:03.174656 2019] [authn_file:error] [pid 7740] (13)Permission denied: [client 10.0.0.10:50429] AH01620: Could not open password file: /home/svn/repository/conf/svn.passwd subversion.conf 配置
# Needed to do Subversion Apache server. LoadModule dav_svn_module modules/mod_dav_svn.so # Only needed if you decide to do "per-directory" access control. LoadModule authz_svn_module modules/mod_authz_svn.so <Location /svn> DAV svn SVNPath /home/svn/repository/repos201911/ AuthType Basic AuthName "Authorization SVN Repo" AuthUserFile /home/svn/repository/conf/svn.passwd AuthzSVNAccessFile /home/svn/repository/conf/svn.authz Require valid-user </Location> /home/svn/repository/repos201911 /home/svn/repository/conf/ 上面这两个目录均执行了chown -R apache.apache授权命令
SELINUX=disabled 是关闭的，而且重启了机器也还是这个错误。
各位老铁们还有什么地方要检查的么？
]]>2)使用的场合不同。Git 适用于通过 Internet，有多个开发角色的单个项目开发，Svn 适合企业内部由项目经理统一协调的多个并行项目的开发。
3)权限管理策略不同。Git 没有严格的权限管理控制，只要有帐号，就可以导出、导入代码，甚至执行回退操作。Svn 则有严格的权限管理，可以按组、按个人进行针对某个子目录的权限控制。区分读、写权限。更严格的，不支持回退操作。保证代码永远可以追踪。
4)分支(branch)的使用范围不一样。Git 中，你只能针对整个仓库作 branch,而且一旦删除，便无法恢复。而 svn 中，branch 可以针对任何子目录，它本质上是一个拷贝操作。所以，可以建立非常多、层次性的 branch,并且，在不需要时将其删除，而以后需要时只要 checkout 老的 svn 版本就可以了。
5)基于第三点，Git 适用于单纯的软件项目，典型的就是一些开源项目，比如 Linux 内核、busybox 等。相反，Svn 擅长多项目管理。比如，你可以在一个 svn 仓库中存放一个手机项目的 bsp/设计文档 /文件系统 /应用程序 /自动化编译脚本，或者在一个 svn 中存放 5 款手机项目的文件系统。git 中必须建立 n(项目数)*m （组件数）个仓库。Svn 中只需要最多 n 或者 m 个就可以了。
6)Git 使用 128 位 ID 作为版本号，而且 checkout 时要注明是哪个 branch,而 svn 使用一个递增的序列号作为全局唯一的版本号，更加简明易懂。虽然可以使用 gittag 来建立一些文字化的别名，但是毕竟那只是针对特殊版本。
7)可跟踪性，git 的典型开发过程为：建立分支，进行开发，提交到本地 master，删除分支。这样做的后果是以前的修改细节会丢失。而在 svn 下做同样的事情，不会丢失任何细节。这里是一个有趣的链接，表明了 git 下典型的工作方式：（以 master 为核心，不断创建新 branch,删除旧 branch):
http://www.kernel.org/pub/software/scm/git/docs/howto/separating-topic-branches.txt
8)局部更新，局部还原。SVN 由于是在每个文件夹建立一个.svn 文件夹来实现管理，所以可以很简单实现局部更新或者还原。假如你只希望更新某些部分，则 svn 可以很好实现。同时代码写错了，同时可以很好实现局部还原，当然 git 也可以通过历史版本还原，但是无法简单地实现局部还原。
SVN 属于集中化的版本控制系统
这种做法带来了许多好处，特别是相较于老式的本地 VCS 来说。现在，每个人都可以一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限。
事分两面，有好有坏。这么做最显而易见的缺点是中央服务器的单点故障。若是宕机一小时，那么在这一小时内，谁都无法提交更新、还原、对比等，也就无法协同工作。如果中央服务器的磁盘发生故障，并且没做过备份或者备份得不够及时的话，还会有丢失数据的风险。最坏的情况是彻底丢失整个项目的所有历史更改记录，被客户端提取出来的某些快照数据除外，但这样的话依然是个问题，你不能保证所有的数据都已经有人提取出来。
Subversion 原理上只关心文件内容的具体差异。每次记录有哪些文件作了更新，以及都更新了哪些行的什么内容。
Subversion 的特点概括起来主要由以下几条：
每个版本库有唯一的 URL （官方地址），每个用户都从这个地址获取代码和数据；
获取代码的更新，也只能连接到这个唯一的版本库，同步以取得最新数据；
提交必须有网络连接（非本地版本库）；
提交需要授权，如果没有写权限，提交会失败；
提交并非每次都能够成功。如果有其他人先于你提交，会提示“改动基于过时的版本，先更新再提交”… 诸如此类；
冲突解决是一个提交速度的竞赛：手快者，先提交，平安无事；手慢者，后提交，可能遇到麻烦的冲突解决。
Git 属于分布式的版本控制系统
自 2005 年诞生于以来，Git 日臻成熟完善，在高度易用的同时，仍然保留着初期设定的目标。它的速度飞快，极其适合管理大项目，它还有着令人难以置信的非线性分支管理系统，可以应付各种复杂的项目开发需求。
与 SVN 不同，Git 记录版本历史只关心文件数据的整体是否发生变化。Git 并不保存文件内容前后变化的差异数据。实际上，Git 更像是把变化的文件作快照后，记录在一个微型的文件系统中。每次提交更新时，它会纵览一遍所有文件的指纹信息并对文件作一快照，然后保存一个指向这次快照的索引。为提高性能，若文件没有变化，Git 不会再次保存，而只对上次保存的快照作一连接。
简略的说，Git 具有以下特点：
Git 中每个克隆(clone)的版本库都是平等的。你可以从任何一个版本库的克隆来创建属于你自己的版本库，同时你的版本库也可以作为源提供给他人，只要你愿意。
Git 的每一次提取操作，实际上都是一次对代码仓库的完整备份。提交完全在本地完成，无须别人给你授权，你的版本库你作主，并且提交总是会成功。
甚至基于旧版本的改动也可以成功提交，提交会基于旧的版本创建一个新的分支。
Git 的提交不会被打断，直到你的工作完全满意了，PUSH 给他人或者他人 PULL 你的版本库，合并会发生在 PULL 和 PUSH 过程中，不能自动解决的冲突会提示您手工完成。
冲突解决不再像是 SVN 一样的提交竞赛，而是在需要的时候才进行合并
和冲突解决。
总之，公司的开发团队在进行的项目开发管理时，svn 是更好的选择，团队成员共同维护公司的中心版本。
若是开源项目，则 git 更加适合，每个人都可以维护自己专属的版本，同时有 github 开源社区支持 ]]>
有人遇到同样的问题吗？
]]>