★ FEATURED ARTICLE 简介面向MyEclipse/Eclipse开发者的SVN插件离线安装包可将Subversion版本控制能力无缝集成到IDE中适合需要频繁提交代码、同步更新、对比差异、处理合并冲突的团队开发场景无需离开编辑器即可完成常用版本控制操作。压缩包共30个文件以27个jar插件库为核心另含一份docx安装说明、一个xml站点配置和一个html帮助文档整体约16.9MB便于无外网或内网环境离线部署。目前已有939人学习或下载适用于MyEclipse 10及同类Eclipse系IDE的本地安装尤其适合无外网环境快速搭建版本控制环境。包内核心为1.8.22版插件整合SVNKit、JavaHL等客户端适配器提供提交、更新、日志查看、分支合并等完整功能features与plugins目录分层清晰site.xml与artifacts.jar共同构成标准Eclipse更新站点便于IDE识别集成。随附的Myeclipse10安装svn插件.docx从添加软件源到重启生效逐步说明配合index.html帮助入口初次接触SVN也能按文档快速完成配置。1. SVN 插件 site-1.8.22老环境里最省事的站点管理插件SVN 1.8 的服务器在现在的运维环境里依然不少见。它们跑着内部代码库稳定得让人想不起来升级可一旦要给仓库加站点式管理很多新插件都装不上去。我在一台老服务器上装 site 插件时就翻过车svnserve 一直报 cant load plugin查了半天才发现是主程序和插件的接口版本差了一代。从那以后我立了一条规矩SVN 主程序是 1.8.x就只用 site-1.8.22 这个配套版本。site-1.8.22 做的事情不复杂把多个 SVN 仓库收拢到一个站点入口里统一浏览和授权省得每次新增仓库都要在 svnserve.conf 里手工加配置。对长期跑着没人动的 1.8 老环境来说它比改一堆脚本省事。正在给 SVN 1.8 老服务器配插件的读者可以直接照着往下走如果环境是 SVN 1.9 以上建议先看第 2 章再做决定。2. 安装前置先把 SVN 主版本和依赖对齐装插件最怕的不是装本身而是装之前没看自己的环境。site-1.8.22 跟 SVN 主程序的绑定非常紧主程序版本对不上后面所有步骤都是白做。所以装之前先把版本和依赖查清楚后面配置才不会返工。2.1 版本对齐site-1.8.22 为什么必须是 SVN 1.8.x先在目标机器上执行这一句把主程序的版本号拿出来svnserve --version输出里第一行就是版本信息正常会看到类似下面的内容svnserve, version 1.8.22 (r1813606) compiled on x86_64-unknown-linux-gnu如果看到的是 1.8.x说明环境对齐了site-1.8.22 可以直接装。我在这台机器上看到的是 SVN 1.8.22和插件的中间版本号正好一致不过插件依赖的是整个 1.8 系列不必强求小版本也完全相同。如果看到的是 1.9 或 1.10就要慎重了site 插件实现时直接调用了 SVN 主程序内部的函数和数据结构SVN 从 1.8 升到 1.9 时改过一批内部接口按 1.8 编译的插件在 1.9 上加载就会报符号缺失。版本不匹配的报错我见过两种svnserve 启动时日志里出现 symbol not found或者直接写 cant load plugin。区别在于前者更像库本身的问题后者更像路径问题但其实根源往往都是版本对不上。这个报错特别容易误导人因为第一眼看上去谁都不会想到是版本问题我就在这上面花过半个下午。所以我的习惯是拿到插件包先打开 INSTALL 或 README把里面写明的适用 SVN 版本记下来再和 svnserve --version 的结果比对。这里还有一个容易混淆的地方site-1.8.22 这个版本号里的 1.8 是它自己的插件版本不是 SVN 的版本但它的命名恰好表示配套 SVN 1.8 系列不能反过来把插件的 1.8.22 直接当成 SVN 的 1.8.22。比对通过了才开始下一步。机器上如果同时装了多个版本的 SVN 客户端还要用 which svnserve 确认 PATH 里实际生效的是哪个 svnserve必要时在启动服务时直接写绝对路径免得重启后被环境变量带偏。2.2 依赖检查装插件前我要确认的三样东西除了主程序版本运行层面还有三个依赖需要提前确认glibc、APR 库和 svn 命令行工具。site-1.8.22 的插件本体是编译好的动态库加载它需要这些库存在而且位数要和主程序一致否则即使版本对上了启动时也会报加载失败。我常用的检查命令是这一组which svnserve # 确认实际生效的 svnserve 路径 ldd $(which svnserve) | grep -E apr|libsvn # 检查动态库依赖 ls /usr/lib/svn 2/dev/null || ls /usr/lib64/svn 2/dev/null第一行看 svnserve 在哪避免被别的版本干扰第二行把 svnserve 依赖的动态库列出来重点看 libsvn 和 apr 开头的库是否存在第三行直接找 SVN 的插件目录。在多数 Linux 发行版里SVN 1.8 的插件目录位于 /usr/lib/svn 或 /usr/lib64/svnsite 插件的落位跟这个风格保持一致比较省事。检查结果分三类处理如果 ldd 输出里缺少 libapr 相关库就去装 apr 和 apr-util 的开发包如果库都在但位数不一致比如 svnserve 是 64 位的、lib 目录里却有 32 位的 apr优先换掉不匹配的库如果整个 /usr/lib/svn 都不存在说明当初装 SVN 选了精简安装这时建议直接把 site 插件放到自己的独立目录里不依赖系统的插件目录。还有一点常在最后暴露装的是源码版插件时机器上得提前备好 gcc、make 和 subversion-devel。site-1.8.22 一般会带编译好的 .so能找到就直接用不带 gcc 也能跑但如果拿到的包里全是 .c 和 .h现场又装不了编译器安装就要卡住。我每次还是会顺手执行一下 gcc --version确认万一用到编译器时不至于临时抓瞎。这里放一张依赖清单方便装前逐项勾掉依赖项检查命令缺少时的处理SVN 主程序 1.8.xsvnserve --version回退或共存见 2.3APR / APR-utilldd $(which svnserve)安装对应的系统包glibc 运行库ldd --version一般系统自带注意位数lib/svn 插件目录ls /usr/lib/svn不存在时用独立目录安装gcc / makegcc --version仅源码版插件需要2.3 版本不对怎么办回退或共存二选一如果前面的检查发现 SVN 主程序是 1.9 或更高而手里只有 site-1.8.22有两个选择。第一个是把系统默认的 svnserve 回退到 1.8.x适合 SVN 服务专机专用第二个是共存安装保留高版本 SVN 不动另外编译一套 1.8 的服务端给 site 插件专用适合服务器上还跑着依赖高版本 SVN 的业务。回退的做法不算复杂从系统软件源里找到 subversion 1.8 的对应包卸载高版本再装回匹配版本。如果系统源里只剩高版本就只能走编译安装这一步要记得同时安装 subversion-devel否则后面插件加载时会缺符号。旧软件的编译依赖在新系统上经常不齐常见的顺序是先装 apr-devel、sqlite-devel再 ./configure --prefix/opt/svn18 make make install花的时间不比插件本身少。共存安装时只需要注意端口和路径我给编译版单独指定了 --prefix/opt/svn18启动脚本里写 /opt/svn18/bin/svnservesite 插件的绝对路径也跟在这套 svnserve 后面这样两套 SVN 互不干扰。监听端口默认是 3690如果高版本服务端也在同一台机器上跑就要在启动参数里指定 --listen-port否则两个进程会抢端口表现就是服务一启动就退出日志里写 address already in use。3. 解压与落位site-1.8.22 的目录结构和安装位置版本和依赖确认完之后就进入部署环节。site-1.8.22 虽然自带安装说明但说明文档默认的是使用方会自己找安装位置实际上每台机器的目录习惯都不一样。我在这台 SVN 1.8 服务器上用的方案是独立目录按以后想卸掉插件直接删目录的原则来放不污染系统原有的 SVN 文件。3.1 拿到包之后先校验再解压从内网拿到的 site-1.8.22 压缩包我一般先算一次哈希和包内附带的校验文件比对。这一步看起来可有可无但二进制插件一旦传输损坏解压时未必报错反而会装完运行时报出更奇怪的错误到时候排查成本高得多。sha256sum site-1.8.22.tar.gz # 计算当前文件哈希 grep site-1.8.22 SHA256SUMS # 对照包内校验记录哈希值对上之后再解压。这里的 grep 如果找不到对应文件名就先查看压缩包解压出的校验文件是什么格式有些包用 md5sum有些用 sha256sum格式不同不要硬套。解压习惯放到临时目录而不是直接在下载目录散开mkdir -p /tmp/site-plugin tar -xzf site-1.8.22.tar.gz -C /tmp/site-plugin ls -la /tmp/site-plugin解压后先 ls 看根目录正常会看到一个带版本号的顶层目录进入之后才是 INSTALL、conf 和 lib。如果压缩包直接解出一地文件没有顶层目录说明打包时就没按标准来我会先在 /tmp 里建专用目录再接进去否则复制时容易把所有文件堆到安装目录里后面维护时一团乱。3.2 目录布局每个文件用来干什么site-1.8.22 包内的目录结构大致是下面这样我把每次都要重点核对的列出来路径作用安装时是否要改INSTALL / README包内自带安装说明读取即可conf/site.conf插件主配置模板复制后必改lib/site-plugin.so插件动态库本体核心文件bin/site-ctl命令行管理工具按需使用sql/ 或 extensions/初始化脚本或扩展一般不动这个结构在压缩包和安装后的目录里保持一致所以复制时千万别把目录层级打散。插件加载时是按配置路径找 site-plugin.so 的路径一旦变了svnserve 启动时只会说找不到插件不会自动扫描全盘。3.3 拷贝与权限安装目录和用户权限这台机器上 SVN 服务是用 svn 这个系统用户跑的所以插件目录的所有者也必须落到 svn 用户。用 root 安装没问题但服务跑起来后如果插件需要写自己的工作目录权限不对会在运行期才暴露比安装时报错难查得多。mkdir -p /usr/local/site-plugin cp -r /tmp/site-plugin/site-1.8.22/* /usr/local/site-plugin/ chown -R svn:svn /usr/local/site-plugin chmod -R 755 /usr/local/site-plugin chmod 750 /usr/local/site-plugin/bin/site-ctl复制时用 cp -r 保留完整的子目录结构而不是只挑几个文件。chown 之后要顺手确认动态库具备可读权限因为 svnserve 加载 .so 时要求文件对运行用户可读目录对运行用户可进入。chmod 给 755 是因为目录需要执行权限才能进入只给 644 的话svnserve 会报一个隐晦的 cant load plugin不会直接说是权限问题。我当时还额外做了一步软链把 lib/site-plugin.so 软链到 /usr/lib/svn/site-plugin.so这样既有独立目录便于管理又能满足一些默认扫描路径的机制。不过这步不是必须的取决于 svnserve 是不是会按系统插件目录自动扫描如果不确定按第 4 章把 --plugins 参数显式写清楚才是更可控的做法。也可以选择直接把 .so 复制进系统原有的 /usr/lib/svn但我在这台机器上没用这个方案。老服务器的系统包里混杂了太多 SVN 相关文件升级系统包时可能被覆盖或者清理掉独立目录更稳当真要卸掉插件时也干净得多。4. 配置与启用三个必改参数和加载方式文件放到位只是第一步真正决定 site-1.8.22 能不能跑起来的是配置。这个插件的配置分两层一层是 site.conf 里插件自身的工作参数另一层是 svnserve 的启动参数决定服务端怎么把插件加载进来。两层都要配只改一层不会生效。4.1 site.conf三个决定生死的参数把包里的 conf/site.conf 复制到安装目录下然后开始改。模板里的参数不少但每次安装真正必须改的只有三个plugin_dir、repo_root、auth_file。其余参数保留默认就能跑顶多按需要调一下日志级别。plugin_dir /usr/local/site-plugin/lib # 插件动态库实际所在目录 repo_root /var/svn/repos # 服务器仓库根目录不是单个仓库 auth_file /var/svn/conf/authz # SVN 原有授权文件路径 log_level info # 首次安装建议开启 infoplugin_dir 必须和 .so 实际位置完全一致。我见过有人把插件装到 /usr/local/site-plugin/lib 底下结果配置里还写着压缩包里的相对路径svnserve 一启动就加载失败这类问题用 pwd 打一遍绝对路径就能避开。repo_root 是插件统一扫描仓库的根目录要写仓库目录的上一级。写错了插件也能正常启动但站点里看到的仓库列表是空的这个现象不看到站点页面根本发现不了。所以在写这个路径之前我会先在终端直接 ls /var/svn 看真实目录名再对照配置文件里的值两边确认一致再保存。auth_file 指向 SVN 原有的 authz 授权文件。路径写错不会在启动时报错但用户访问仓库时会一直认证失败而且日志里看不出和插件有什么关系容易绕一大圈。首次配置完成后我会特意用带认证参数的 svn info 连一次仓库地址确认这层没有配错。4.2 把插件加载进 svnservesite.conf 改完之后还要让 svnserve 启动时真正加载插件。我在这台机器上用的方式是修改系统服务配置在启动命令里加一个 --plugins 参数指向 site-plugin.so 的绝对路径systemctl edit svnserve在编辑器里覆盖 ExecStart 这一行写成[Service] ExecStart/usr/bin/svnserve --daemon --root /var/svn/repos --plugins /usr/local/site-plugin/lib/site-plugin.so之所以要把完整路径写进启动参数是因为旧机器上的 PATH 环境变量不一定包含 /usr/local/site-plugin如果系统里还装了另一个 svnserve靠相对路径很可能加载到错误的文件。--root 参数也顺便明确指定了仓库根目录和 site.conf 里的 repo_root 保持一致两边都指着 /var/svn/repos配置起来不容易看岔。有些发行版把 svnserve 放到 /usr/bin 之外用 which svnserve 查到的位置为准。如果机器上用的是老式 init 脚本而不是 systemd就用同样的逻辑改 /etc/rc.d/init.d/svnserve 里的启动命令行把 --plugins 参数原样加进去。这一步漏掉的隐患是手动启动时插件生效了服务器一重启svnserve 被旧脚本拉起来插件就丢了表现和没装一样。4.3 重启服务与日志确认配置改完重启服务并立刻检查状态systemctl restart svnserve systemctl status svnserve --no-pager journalctl -u svnserve -n 30 --no-pagersystemctl status 的作用是确认服务没有启动失败。如果状态不是 active (running)先不要往下走回头检查启动参数和配置文件如果服务正常再看 journalctl 的最近日志里有没有插件相关的加载记录。site 插件加载成功时日志里一般会出现 plugin loaded 或 site plugin initialized 这类文本看到之后基本可以放心。如果这台机器没有 journald就去 /var/log/svnserve 或 syslog 里看同样关键词或者直接在 ps -ef | grep svnserve 的输出里确认 --plugins 参数确实存在于当前进程。第一次装的时候我习惯把日志级别开成 info等确认跑通了再调回 warning这样既能保留有效信息又不会让日志刷得太杂。顺手还可以用 ss -ltnp | grep 3690 确认监听端口起来了这一步能把服务起没起和插件加没加载分开来看排查时心里更有数。5. 安装避坑site-1.8.22 的五个高频翻车现场这个插件在使用中最折磨人的一点是报错信息跟真实原因经常对不上。有些问题表面上在说文件路径实际上是版本不匹配有些问题日志里什么都不写结果只是配置文件里一个路径写错了。这一章整理五个实际遇到的场景按现象、原因、解决的顺序写遇到相似问题时可以先对号入座。5.1 版本不匹配与加载失败第一个坑svnserve 启动报 symbol not found看起来像是库被损坏。现象服务启动后日志里出现 symbol not found: svn_xxx 的报错插件文件明明存在用 file 查看 .so 也说格式正常。原因svnserve 主程序是 1.9 或更高版本而 site-1.8.22 按 SVN 1.8 的接口编译两个版本的内部符号不兼容加载时找不到对应函数入口。这不是文件损坏也不是路径问题是版本对不上。解决回到第 2 章的版本对齐步骤。这台机器最终把 SVN 服务端换成了 1.8.22与 site-1.8.22 配套后一次加载成功。如果是共存环境确认 --plugins 指向的 svnserve 真的是 1.8 那套别被 PATH 里的高版本抢先了。第二个坑svnserve 启动时报 cant load plugin但插件文件就在指定路径。现象启动命令里 --plugins 指向 /usr/local/site-plugin/lib/site-plugin.sols 也能看到文件svnserve 就是起不来。原因路径细节写错了。这个坑我踩过两次一次是 site-plugin.so 被写成 site_plugin.so下划线写错另一次是目录末尾多了一个斜杠写成 lib/svnserve 对路径做精确匹配多一个字符都会失败。解决在终端先 cd 到 lib 目录用 echo $PWD/site-plugin.so 把绝对路径原样打出来再粘贴到启动参数里。这个方法能挡住大部分手打路径的错比盯着字符串硬看效率高很多。5.2 路径权限与生效类第三个坑svnserve 没报任何错误站点里却看不到仓库。现象服务正常运行插件加载成功站点入口的仓库列表却是空的。原因site.conf 里的 repo_root 指错了目录。我最早一次配到了 /var/svn但实际仓库根目录在 /var/svn/repos插件按前面那个路径去扫描一个仓库都扫不到。解决用 ls /var/svn 确认真实仓库根目录再回 site.conf 里核对 repo_root。这一步要注意的是别只盯着配置文件看实际目录结构以服务器上的显示为准我在别的机器上还见过仓库目录被挂在 /data/svn 下的情况照搬默认路径一样会踩空。第四个坑插件加载成功客户端连接时却一直认证失败。现象svn list svn://localhost/repos 一直报认证错误svnserve 日志里看不到插件有异常。原因auth_file 配置指向了 SVN 原有 authz 文件但那份文件里没有定义插件站点入口对应的读权限访问在权限这一层就被拦住了。解决在 authz 里补充插件路径对应的授权规则或者把 site.conf 的 auth_file 改成实际生效的那份授权文件。改完重启 svnserve再用带认证参数的 svn info 重新测一次。这个坑最容易绕远路因为是认证报错第一反应都会去查账号密码很少有人第一时间想到是插件配置里的路径问题。第五个坑服务器重启之后插件失效。现象装完当天一切正常重启后 site 功能消失svnserve 进程还在但插件没加载。原因svnserve 不是由刚配置的 systemd 服务拉起来的而是由旧的 init 脚本或其他调度工具启动我改的 ExecStart 没有作用到真实的启动路径。解决用 ps -ef | grep svnserve 看当前进程的完整启动参数确认实际启动入口。老服务器上 systemd 和 init 脚本并存的情况不少改完一处要多检查另一处如果两个启动入口都在最好同步改成同一套参数避免下次重启又出现同样的问题。6. 装完怎么验证用一条命令确认插件真的跑起来验证是安装流程的最后一关也是我最不愿意省的一关。site-1.8.22 装完以后光看服务状态还不够服务起来不代表插件已经加载插件加载了也不代表仓库路径能被正确访问。我会按顺序做三件事。先看插件是否被 svnserve 识别svnserve --version | grep -i plugin这条命令会列出 svnserve 运行时加载的插件信息如果 site 插件出现在结果里说明加载机制已经生效。如果这里看不到基本可以断定是启动参数或路径问题这时候先不用去动仓库回来查 ExecStart 和 site.conf 更省时间。接着在仓库上执行一次实际访问验证svn info svn://localhost/repos --non-interactive能正常返回仓库信息说明认证、授权和仓库根目录在这一层都是通的。这一步通过以后再到站点入口检查仓库列表通常看到的就是正常列表而不是空的了。如果这一步报认证失败优先查 auth_file 指向和 authz 规则。最后用日志做端到端确认journalctl -u svnserve -n 50 | grep -E site|plugin日志里能看到插件启动记录才算最终闭环。我一般看完这三步才敢把机器交回去。有一次我图省事装完只 systemctl status 看了一眼就收工结果第二天发现站点里仓库列表全空回头查才发现 repo_root 指错了位置。从那以后每次装完这类服务插件我都会强制走一遍 svnserve --version、svn info、日志确认这三个动作特别是版本和路径这两处确认没跑偏才放心。希望这套验证流程也能帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
