简介这份面向 Eclipse 与 MyEclipse 开发者的 SVN 集成插件包对应 site-1.8.22 版本提供可挂载的更新站点资源及配套安装说明用于在 IDE 内接入 Subversion完成代码提交、更新、差异对比、历史查看与冲突处理等版本控制操作1.8.x 系列在目录属性支持、性能表现与冲突解决机制上相对成熟适合维护旧项目的开发者按需选用。压缩包共 30 个文件以 27 个 jar 插件组件与依赖库为主涵盖客户端适配、图形化历史、合并跟踪等模块另含 1 个 docx 安装文档、1 个 xml 站点描述和 1 个 html 入口页整体约 16.9MB既方便离线部署也便于按组件排查依赖关系。已有 940 人学习说明该版本在旧版 IDE 环境中仍有一定参考价值。读者可获得较完整的更新站点目录和适配 MyEclipse 10 的图文指引能够理解插件、特性与依赖库之间的对应关系降低版本不兼容、依赖缺失等安装排查成本并为日常 SVN 客户端使用打好基础。1. 装完插件却在菜单里找不到 SVN版本没对齐的坑第一次在一台不能联外网的构建机上给 Eclipse 装 SVN 插件我把 site-1.8.22 解压后整个目录塞进 dropins重启Perspective 里翻了三遍也没找到 SVN 那一项。后来才看清是解压时多套了一层文件夹Eclipse 根本没扫到 features 和 plugins。这种坑在离线环境里出现得太频繁了机器上不了外网更新站点只能用本地包插件版本还得同时跟 Eclipse、JDK、命令行 SVN 客户端以及同事已经拉下来的工作副本格式对上。site-1.8.22 属于 1.8.x 这一支主要服务于还停在 SVN 1.6/1.7 工作副本上的老项目常见于内网开发机、持续集成的构建节点以及 Eclipse 版本不新但一时半会儿换不掉的团队。装不好不会报错只会看起来装上了、用起来全是毛病。2. 环境对齐site-1.8.22 要的 Eclipse、JDK 和 SVN 客户端装插件之前先把手上的四样东西点清楚Eclipse 版本、跑 Eclipse 的那个 JVM、命令行 SVN 的版本、以及已有工作副本的格式版本。这四样里任何一样超标插件都能装上但会在某个具体操作上翻车——最常见的是检出直接失败或者提交时提示工作副本格式不支持。2.1 一张表看清 site-1.8.22 的适配范围组件这一支的适配范围怎么确认Eclipse3.6 及以上4.x 多数可用4.6 之后建议换更新的插件分支Help About Eclipse 看版本号JDK / JRE1.6 起步实际部署建议统一到 1.8Help Installation Details Configuration 搜 java.version命令行 SVN1.6 / 1.7 为主svn --version --quiet工作副本格式1.6 / 1.7sqlite3 .svn/wc.db PRAGMA user_version;这张表不是让你背是让你在装之前先做减法。Eclipse 4.6 以后的版本插件加载机制和老的更新站点格式配合得没那么顺装得上也可能缺菜单项这种时候不必硬扛直接换更新的插件分支比修配置省时间。反过来Eclipse 3.6/3.7 上装最新的插件分支多半会因为最低 Java 版本要求或者 API 变动直接罢工所以也别一味求新。我一般会把这张表抄进部署脚本的头部注释里谁接手谁先看一遍省得每次换机器都要重新踩一遍。2.2 确认 Eclipse 版本和它实际用的 JVM很多人查 Eclipse 版本只在界面上看但装插件出问题时真正要紧的是它启动时加载的那个 JVM而不是系统环境变量里的默认 java。这两个经常不是同一个尤其是机器上装过多个 JDK 的情况。# Eclipse 的版本号和 build id 都存在这个文件里离线机器上直接读文件最快 cat $ECLIPSE_HOME/.eclipseproduct # 输出大致如下version 是主版本id 里带构建日期 # nameEclipse Platform # idorg.eclipse.platform # version4.4.2.eclipseproduct里的 version 就是判断插件分支能不能用的第一依据。如果文件不存在有些精简发行版会删掉就退回到界面里 Help About Eclipse 看。接下来确认 JVM这一步比上一步更容易出问题# -vm 参数写在 -vmargs 之前且必须单独占一行路径里不要加引号 grep -A1 ^-vm$ $ECLIPSE_HOME/eclipse.ini # 看看系统默认的 java 是哪一版注意它和上面那个不一定是同一个 java -version 21 | head -3-vm后面那行才是 Eclipse 真正用的 Java 可执行文件。如果 grep 没输出说明 Eclipse 在用系统 PATH 里找到的 java这种情况在同时装了 32 位和 64 位 JDK 的机器上极易出岔子插件里的 JavaHL 本地库是随架构走的64 位 Eclipse 加载 32 位 dll 只会给一句很模糊的错误。确认完版本顺手记一下位数# 确认 JVM 位数x86_64 是 64 位i386 是 32 位 java -XshowSettings:properties -version 21 | grep sun.arch.data.model输出 64 就说明是 64 位插件里带的本地库也必须是 64 位。这条信息后面排查 JavaHL 加载失败时会反复用到。2.3 装好命令行 SVN 并锁住版本插件本身不一定要命令行客户端才能跑SVNKit 是纯 Java 实现但离线环境里我强烈建议装一个命令行 svn理由有三个它能帮你确认工作副本格式、能在插件出问题时交叉验证到底是服务端还是客户端的问题、还能在脚本里做前置检查。# Debian/Ubuntu 系 sudo apt-get install -y subversion # RHEL/CentOS 系 sudo yum install -y subversion # 只打版本号方便写进部署脚本做前置校验 svn --version --quiet # 完整信息里重点看两处版本号以及支持的访问协议模块 svn --version | head -6--quiet这个参数在写自动化脚本时特别有用它只输出一行纯版本号不用再拿 sed 去抠。完整输出里会列出 ra_neon、ra_serf、ra_svn 这些模块走 http 协议的仓库依赖 ra_neon 或 ra_serf如果这两个模块缺失命令行能连上的仓库插件不一定连得上反过来也一样。版本要锁。SVN 客户端版本比服务端高一到两个小版本通常没事但工作副本格式是单向升级的命令行 svn 1.8 只要对该目录执行过一次写操作工作副本就会被升级到 1.8 格式此后 site-1.8.22 这套插件就再也读不了它。所以在同一台机器上命令行 svn 和插件支持的格式版本必须保持一致。2.4 查清已有工作副本的格式别轻易升级接手别人的工作目录时第一件事不是检出是看格式。# 工作副本格式号存在 wc.db 里1.7 之后都是 SQLite 数据库 cd /data/workspace/legacy-project sqlite3 .svn/wc.db PRAGMA user_version;这个数字对应关系大致是10 对应 1.6 格式29 对应 1.7 格式31 对应 1.8 及以后。读到 29 说明还在 site-1.8.22 的处理范围内读到 31 就要停一下了这套插件很可能打不开它强行打开会提示工作副本格式过新。如果确实需要升级格式命令是svn upgrade但这个操作没有后悔药# 升级前先备份整个工作副本升级是不可逆的 cp -a /data/workspace/legacy-project /data/backup/legacy-project-$(date %Y%m%d) # 执行升级只升级格式不动文件内容 svn upgrade /data/workspace/legacy-project # 升级后确认格式号变化 sqlite3 /data/workspace/legacy-project/.svn/wc.db PRAGMA user_version;升级完成之后旧版客户端和旧版插件就彻底进不去了团队里只要还有一个人在 Eclipse 里用 site-1.8.22你这一升就等于把他踢出协作。所以升级前先问清楚所有人用的插件版本这一步比备份还重要。3. 三种装法把 site-1.8.22 塞进 Eclipse 的具体步骤site 包本质上是一个离线更新站点解压后能看到 features、plugins 两个目录以及一个 site.xml。三种装法对应三种场景能打开 Eclipse 界面时用本地站点安装最稳批量铺机器时用 dropins 或 links 更省事。先把包解开、看清结构再决定用哪种。# 先看压缩包里到底有什么别急着解压 unzip -l site-1.8.22.zip | head -20 # 典型输出里应该能看到这些 # features/ # plugins/ # site.xml # content.jar # artifacts.jar有 site.xml 说明它是老式更新站点Eclipse 4.x 仍然认有 content.jar 和 artifacts.jar 说明它同时被包装成了 p2 仓库两种方式都能读。看清之后再决定解压到哪。# 统一放到一个插件仓库目录后面三种装法都从这里取 sudo mkdir -p /opt/eclipse-plugins sudo unzip -q site-1.8.22.zip -d /opt/eclipse-plugins/svn-1.8.22 # 确认解压结果的层级features 和 plugins 必须直接在这一层 ls /opt/eclipse-plugins/svn-1.8.22这一步用ls确认层级是整篇文章里最便宜也最有效的一次检查。第 1 章开头那个坑就是多套了一层site-1.8.22/site-1.8.22/featuresEclipse 扫不到装完什么也没发生。3.1 方式一从本地站点安装可控性最好能进图形界面就优先用这个方式因为它会把安装记录写进 p2 的 profile卸载干净、升级路径清晰。操作路径是 Help Install New Software Add Local选中/opt/eclipse-plugins/svn-1.8.22这一层目录注意别选到 features 里面去。列表里会列出可装的组件勾选 SVN Team Provider 一类的条目一路 Next接受协议最后重启。如果在 Add 的对话框里选择 Archive 直接指向 zip也行。区别在于 Archive 方式每次重装都要重新解压一遍Local 方式指向的是已解压目录后面改配置或者打补丁更方便。装完先别急着用做一次清理启动# -clean 会重建插件的注册缓存-consoleLog 把日志打到控制台方便看 $ECLIPSE_HOME/eclipse -clean -consoleLog -nosplash-clean只影响插件缓存不动工作空间和代码可以放心加。-consoleLog在有问题的机器上一定要带很多加载失败只在这行输出里露出真话。3.2 方式二dropins 目录解包安装适合批量铺机器dropins 是 Eclipse 给免安装式插件留的口子把 features 和 plugins 按约定摆进去就行。前提是目录层级必须严格dropins 下面那层可以是任意名字的文件夹但再往下必须直接是 features 和 plugins。# 建一个独立子目录名字随意但不能直接平铺文件 mkdir -p $ECLIPSE_HOME/dropins/svn-1.8.22 # 把两个目录整体拷进去注意是拷目录本身不是拷目录里的内容 cp -r /opt/eclipse-plugins/svn-1.8.22/features $ECLIPSE_HOME/dropins/svn-1.8.22/ cp -r /opt/eclipse-plugins/svn-1.8.22/plugins $ECLIPSE_HOME/dropins/svn-1.8.22/ # 检查结果这两个路径必须都存在 ls $ECLIPSE_HOME/dropins/svn-1.8.22拷完之后同样要带-clean启动一次。Eclipse 4.x 对 dropins 的支持还在但行为比 3.x 严格带 jar 的插件包要保证 MANIFEST 里声明了正确的 Bundle-SymbolicName不然扫描时会被静默跳过。这也是为什么很多人反馈dropins 放了没反应其实不是没扫是扫到了但被判定为无效。要卸载的时候直接把dropins/svn-1.8.22整个删掉再-clean启动一次就干净了。这一点比方式一省心适合一次性铺十几台构建机的场景。3.3 方式三links 挂载多套 Eclipse 共用一份插件一台机器上装了两三个 Eclipse做兼容性验证时很常见的时候dropins 的写法要重复好几份占空间还容易版本不一致。links 方式能把插件放在公共目录让多个 Eclipse 实例共享同一份。# 文件路径为 $ECLIPSE_HOME/links/svn-1.8.22.link # 内容只有一行指向插件根目录含 features 和 plugins 的那一层 path/opt/eclipse-plugins/svn-1.8.22Windows 上路径要写双反斜杠且不要写成单个反斜杠也不要在等号后面加空格pathD:\\eclipse-plugins\\svn-1.8.22.link文件的扩展名必须是 link内容里 path 后面跟的必须是绝对路径。写完同样要-clean启动一次否则 Eclipse 不会重新扫描 links 目录。这个方式的另一个好处是插件目录和 Eclipse 安装目录彻底分离Eclipse 升级覆盖安装时插件不受影响。3.4 装完先验证插件有没有被真正加载三种方式装完都要先做一次加载验证再谈配置。验证方法是从 Help About Eclipse Installation Details Plugins 页签里搜关键词或者直接看 configuration 目录下的日志# 安装细节里的已装插件列表是最直接的证据 grep -i svn $ECLIPSE_HOME/configuration/*.log | tail -20日志里如果出现 version 冲突、Missing Constraint、requires bundle 之类的字样说明插件依赖没满足多半是 Eclipse 版本偏高或偏低这时候继续往下配 SVN 接口是浪费时间先把版本对齐。4. 配置 SVN 接口JavaHL 与 SVNKit 怎么选、路径怎么写插件装上了Team 菜单里也出现了 SVN但第一次点检出就报 Unable to load default SVN Client这是第二道坎。根因几乎都在 SVN 接口这一层插件自己有界面真正干活的底层实现有三种选错了或者路径没配对界面上一切正常操作时全失败。4.1 三种接口的取舍接口依赖适合场景主要短板JavaHL本地 JavaHL 库随 SVN 客户端提供需要完整语义文件锁、属性操作要求严格架构和路径必须完全对上配错就没法用SVNKit纯 Java无本地库跨平台、临时机器、不想折腾本地库个别高级特性支持不完整命令行客户端本机 svn 可执行文件已经装了命令行 svn想复用同一套认证每次操作起一个进程速度偏慢我的默认选择是长期使用的开发机、构建机配 JavaHL临时排障、虚拟机快照、不想装本地库的场景切 SVNKit已经有稳定的命令行 svn 并且团队习惯一致的环境用命令行接口最省心。切换位置在 Window Preferences Team SVNSVN Interface 一栏的 Client 下拉里。下拉里如果只显示 SVNKit说明 JavaHL 没被加载成功此时不用改别的先去解决本地库。4.2 JavaHL 的 java.library.path 配置JavaHL 是一个 JNI 桥Eclipse 启动时要去java.library.path里找本地库文件。Windows 上是svnjavahl-1.dllLinux 上是libsvnjavahl-1.so。找不到下拉里就只有 SVNKit。最稳的做法是把路径写进 eclipse.ini而不是靠系统环境变量因为很多机器上 PATH 是给命令行用的GUI 程序继承不到。# eclipse.ini 关键片段注意顺序 -vm C:/Java/jdk1.8.0_201/bin/javaw.exe -vmargs -Dosgi.requiredJavaVersion1.8 -Xms512m -Xmx1024m -Djava.library.pathC:/Program Files/TortoiseSVN/bin;C:/Windows/System32几个参数必须说清楚-vm必须写在-vmargs之前而且要单独占一行下一行写完整路径路径里不要加引号。写在-vmargs之后的话 Eclipse 会把它当成 JVM 参数传给 Java直接启动失败。-Djava.library.path在 Windows 上多个路径用分号分隔Linux 上用冒号。路径里带空格是可以的但整行不要加引号加了反而会被当成路径的一部分。-Xmx别调太小。SVN 检出大仓库时插件会把变更列表读进内存堆不够会在检出中途抛 OutOfMemory表现却像网络超时很难查。Linux 上的写法-vmargs -Dosgi.requiredJavaVersion1.8 -Xms512m -Xmx1024m -Djava.library.path/usr/lib/jni:/usr/lib/x86_64-linux-gnu/jni/usr/lib/jni是 Debian 系 libsvn-java 包安装本地库的默认位置RHEL 系一般装在/usr/lib64。装完包先确认库文件在哪再写进 ini不要凭记忆写路径# 找到 libsvn-javahl 的实际位置以实际输出为准 find /usr -name libsvnjavahl* 2/dev/null改完 eclipse.ini 一定要带-clean重启。如果下拉里能选到 JavaHL 并显示版本号说明这一层通了。4.3 SVNKit 的适用边界SVNKit 是纯 Java 实现不需要本地库也不用管 32/64 位切过去就能用。它的短板在一些边界操作上工作副本的锁定语义、部分属性递归操作、以及和服务端版本的兼容性偶尔会和 JavaHL 表现不一致。遇到某人能提交某人不能提交这种玄学问题时第一件事就是让两个人把 SVN Interface 统一下来。同一个团队里一半 JavaHL 一半 SVNKit是最容易出现我这边好好的这类无解对话的配置。4.4 认证缓存、忽略列表和行尾符接口选好之后有三项配置建议一次性配到位省得后面反复改。认证缓存位置跟随命令行客户端不跟随插件# Linux/macOS ls ~/.subversion/auth/svn.simple/ # Windows 在 %APPDATA%\Subversion\auth改过密码之后插件一直报认证失败八成是这里存着旧凭据。把auth目录整个删掉下次操作会重新提示输入比重启 Eclipse 有效得多。忽略列表在 Preferences Team Ignored Resources 里维护和.gitignore类似但语法弱得多只支持通配符。项目级的忽略规则还是老老实实用svn:ignore属性属性会跟着仓库走团队里所有人一致。行尾符的问题在混合操作系统团队里几乎必然出现。配置在客户端的 config 文件里# ~/.subversion/configWindows 为 %APPDATA%\Subversion\config [miscellany] enable-auto-props yes [auto-props] *.java svn:eol-stylenative *.xml svn:eol-stylenative *.properties svn:eol-stylenative *.sh svn:eol-styleLF;svn:executable *.bat svn:eol-styleCRLFenable-auto-props是总开关不开的话下面这段全部无效。native表示按当前操作系统自动转换检出到 Windows 是 CRLF检出到 Linux 是 LF。svn:executable只对脚本有意义作用是保留可执行位不加的话从 Windows 提交上去的 shell 脚本在 Linux 上拉下来没有执行权限。这两行配置能省掉大量文件内容一样但 diff 一片红的排查时间。5. 排查装 site-1.8.22 最容易翻车的五个地方前面几章的步骤走对了大部分机器能一次通。剩下那部分机器问题基本集中在下面五类。每条按现象、原因、解决三段来看能省掉很多瞎试的时间。5.1 现象插件放进 dropins 重启后毫无反应原因九成是目录层级错。dropins 下面允许有一层任意命名的文件夹但再往下必须直接是 features 和 plugins如果解压时多套了一层svn-1.8.22/svn-1.8.22/Eclipse 扫描到这一层找不到清单文件就静默跳过了不报错。解决先ls确认层级把多出来的那层去掉确认无误后带-clean重启。如果还是不生效看configuration/*.log那里会有被跳过的插件清单和原因。5.2 现象Preferences 里只有 SVNKit选不到 JavaHL原因本地库没被找到或者位数不匹配。64 位 Eclipse 加载 32 位 dll 只会给一句很模糊的失败日志里也不一定写全。解决先用java -XshowSettings:properties -version确认 JVM 位数再确认本地库位数一致然后用find定位库文件真实路径写进 eclipse.ini 的-Djava.library.path。改完-clean重启。实在对不上先切 SVNKit 把活干完再回头收拾 JavaHL不要卡在这一步上耽误进度。5.3 现象检出时报工作副本格式过新或过旧原因工作副本格式和插件支持的格式不匹配。过新是别的客户端升过格式过旧是仓库里留着很久以前的工作副本。解决先查格式号再决定方向。过新只能用新版客户端处理或者换更新的插件分支过旧执行svn upgrade但升级前必须备份并通知团队因为升级不可逆。这条坑的血泪经验是不要在没有备份的情况下对别人的工作目录执行任何写操作包括看起来无害的svn update。5.4 现象中文路径或提交信息乱码原因工作空间编码、JVM 默认编码、系统 locale 三者不一致。Eclipse 默认用平台编码Windows 中文环境是 GBK提交到服务端就成了乱码。解决在 eclipse.ini 的-vmargs后面加-Dfile.encodingUTF-8同时在 Preferences General Workspace 里把 Text file encoding 设成 UTF-8。两台机器都要改只改一台等于没改。改完重启历史提交信息里的乱码不会自动修复但新提交会正常。5.5 现象提交卡住、目录被锁、cleanup 也解不开原因.svn/wc.db被别的进程占着最常见的是文件索引服务、杀毒软件实时扫描或者上一次操作中途断网留下的残留锁。解决先关掉所有占用该目录的程序包括另一个 Eclipse 实例和资源管理器的预览然后执行svn cleanup勾选 Break locks如果仍然无效把改动过的文件复制出来重新检出一份干净的工作副本再把文件覆盖回去。最后这一步看起来笨但在锁状态彻底坏掉的情况下比重装服务器快得多。6. 验证跑通一次检出、改一行、提交、再还原装完不做验证等于没装。我习惯用一条完整的最小闭环来验收从仓库检出到本地改一行提交上去再从历史里查回来最后还原本地改动。这五步覆盖了认证、读、写、历史查询和本地回滚任何一层没配对都会在这个闭环里暴露。验证项操作或命令期望结果仓库连接SVN Repository Exploring 透视图添加仓库地址能展开 trunk、branches、tags检出右键仓库目录 Checkout选工作空间路径本地出现完整目录无报错状态识别右键项目 Team Show SVN Annotate 或查看图标文件夹上有版本标记无问号提交改一行文件 Team Commit提交成功文件图标恢复干净状态历史查询Team Show History能看到刚才那条提交记录本机还原再改一行 Team Revert改动被丢弃文件回到上次提交状态命令行交叉验证svn status/svn log -l 3输出与图形界面一致无锁、无冲突命令行交叉验证这一步值得单独强调它是判断到底是插件问题还是工作副本问题的分水岭# 进入刚才用插件检出出来的目录 cd /data/workspace/legacy-project # status 第一列是本地改动标记第二列是属性标记没有任何输出说明工作副本干净 svn status # 只看最近三条提交确认插件提交的记录在服务端确实存在 svn log -l 3 # 用命令行再提交一次验证认证缓存和插件用的是不是同一套凭据 echo verify README.md svn commit -m verify from cli README.md如果图形界面报错但命令行正常问题一定在插件这一侧回到第 4 章查接口和路径如果两边都报错问题在工作副本或服务端跟插件版本没关系。这条判断路径能省掉大量来回折腾。svn status的输出约定要记住第一列M是内容被改A是新增D是删除第二列M是属性被改?是未纳入版本控制L是被锁。看到L就按 5.5 处理别硬提交。还有一个容易被忽略的验证点换一台机器重新走一遍检出。插件的问题经常带环境依赖在你机器上好好的到同事机器上就加载失败。所以我每次装完都会把 eclipse.ini 的关键段落和插件目录结构一起记进部署文档让第二个人照着文档独立装一遍装不通就说明文档缺东西。从那以后我每次给新机器装这套环境都会强制先跑一遍查 Eclipse 版本、查 JVM 位数、查命令行 SVN 版本、查工作副本格式这四查再动手解压插件包最后用检出加提交的闭环收尾一套走完才把机器交付出去。前面省下的每一步后面都会以两倍的时间还回来。希望帮到你。这份 site-1.8.22 的离线包和随包带的安装说明我已经放在下载区按上面第 3 章三种装法里挑一种对应你机器的配完回来跑一遍第 6 章的闭环就算装好了。本文还有配套的精品资源点击获取 
长河君 · 2026/10/29 2:23:41 · 阅读 1.2k Eclipse SVN插件site-1.8.22离线安装与JavaHL排错
简介这份面向 Eclipse 与 MyEclipse 开发者的 SVN 集成插件包对应 site-1.8.22 版本提供可挂载的更新站点资源及配套安装说明用于在 IDE 内接入 Subversion完成代码提交、更新、差异对比、历史查看与冲突处理等版本控制操作1.8.x 系列在目录属性支持、性能表现与冲突解决机制上相对成熟适合维护旧项目的开发者按需选用。压缩包共 30 个文件以 27 个 jar 插件组件与依赖库为主涵盖客户端适配、图形化历史、合并跟踪等模块另含 1 个 docx 安装文档、1 个 xml 站点描述和 1 个 html 入口页整体约 16.9MB既方便离线部署也便于按组件排查依赖关系。已有 940 人学习说明该版本在旧版 IDE 环境中仍有一定参考价值。读者可获得较完整的更新站点目录和适配 MyEclipse 10 的图文指引能够理解插件、特性与依赖库之间的对应关系降低版本不兼容、依赖缺失等安装排查成本并为日常 SVN 客户端使用打好基础。1. 装完插件却在菜单里找不到 SVN版本没对齐的坑第一次在一台不能联外网的构建机上给 Eclipse 装 SVN 插件我把 site-1.8.22 解压后整个目录塞进 dropins重启Perspective 里翻了三遍也没找到 SVN 那一项。后来才看清是解压时多套了一层文件夹Eclipse 根本没扫到 features 和 plugins。这种坑在离线环境里出现得太频繁了机器上不了外网更新站点只能用本地包插件版本还得同时跟 Eclipse、JDK、命令行 SVN 客户端以及同事已经拉下来的工作副本格式对上。site-1.8.22 属于 1.8.x 这一支主要服务于还停在 SVN 1.6/1.7 工作副本上的老项目常见于内网开发机、持续集成的构建节点以及 Eclipse 版本不新但一时半会儿换不掉的团队。装不好不会报错只会看起来装上了、用起来全是毛病。2. 环境对齐site-1.8.22 要的 Eclipse、JDK 和 SVN 客户端装插件之前先把手上的四样东西点清楚Eclipse 版本、跑 Eclipse 的那个 JVM、命令行 SVN 的版本、以及已有工作副本的格式版本。这四样里任何一样超标插件都能装上但会在某个具体操作上翻车——最常见的是检出直接失败或者提交时提示工作副本格式不支持。2.1 一张表看清 site-1.8.22 的适配范围组件这一支的适配范围怎么确认Eclipse3.6 及以上4.x 多数可用4.6 之后建议换更新的插件分支Help About Eclipse 看版本号JDK / JRE1.6 起步实际部署建议统一到 1.8Help Installation Details Configuration 搜 java.version命令行 SVN1.6 / 1.7 为主svn --version --quiet工作副本格式1.6 / 1.7sqlite3 .svn/wc.db PRAGMA user_version;这张表不是让你背是让你在装之前先做减法。Eclipse 4.6 以后的版本插件加载机制和老的更新站点格式配合得没那么顺装得上也可能缺菜单项这种时候不必硬扛直接换更新的插件分支比修配置省时间。反过来Eclipse 3.6/3.7 上装最新的插件分支多半会因为最低 Java 版本要求或者 API 变动直接罢工所以也别一味求新。我一般会把这张表抄进部署脚本的头部注释里谁接手谁先看一遍省得每次换机器都要重新踩一遍。2.2 确认 Eclipse 版本和它实际用的 JVM很多人查 Eclipse 版本只在界面上看但装插件出问题时真正要紧的是它启动时加载的那个 JVM而不是系统环境变量里的默认 java。这两个经常不是同一个尤其是机器上装过多个 JDK 的情况。# Eclipse 的版本号和 build id 都存在这个文件里离线机器上直接读文件最快 cat $ECLIPSE_HOME/.eclipseproduct # 输出大致如下version 是主版本id 里带构建日期 # nameEclipse Platform # idorg.eclipse.platform # version4.4.2.eclipseproduct里的 version 就是判断插件分支能不能用的第一依据。如果文件不存在有些精简发行版会删掉就退回到界面里 Help About Eclipse 看。接下来确认 JVM这一步比上一步更容易出问题# -vm 参数写在 -vmargs 之前且必须单独占一行路径里不要加引号 grep -A1 ^-vm$ $ECLIPSE_HOME/eclipse.ini # 看看系统默认的 java 是哪一版注意它和上面那个不一定是同一个 java -version 21 | head -3-vm后面那行才是 Eclipse 真正用的 Java 可执行文件。如果 grep 没输出说明 Eclipse 在用系统 PATH 里找到的 java这种情况在同时装了 32 位和 64 位 JDK 的机器上极易出岔子插件里的 JavaHL 本地库是随架构走的64 位 Eclipse 加载 32 位 dll 只会给一句很模糊的错误。确认完版本顺手记一下位数# 确认 JVM 位数x86_64 是 64 位i386 是 32 位 java -XshowSettings:properties -version 21 | grep sun.arch.data.model输出 64 就说明是 64 位插件里带的本地库也必须是 64 位。这条信息后面排查 JavaHL 加载失败时会反复用到。2.3 装好命令行 SVN 并锁住版本插件本身不一定要命令行客户端才能跑SVNKit 是纯 Java 实现但离线环境里我强烈建议装一个命令行 svn理由有三个它能帮你确认工作副本格式、能在插件出问题时交叉验证到底是服务端还是客户端的问题、还能在脚本里做前置检查。# Debian/Ubuntu 系 sudo apt-get install -y subversion # RHEL/CentOS 系 sudo yum install -y subversion # 只打版本号方便写进部署脚本做前置校验 svn --version --quiet # 完整信息里重点看两处版本号以及支持的访问协议模块 svn --version | head -6--quiet这个参数在写自动化脚本时特别有用它只输出一行纯版本号不用再拿 sed 去抠。完整输出里会列出 ra_neon、ra_serf、ra_svn 这些模块走 http 协议的仓库依赖 ra_neon 或 ra_serf如果这两个模块缺失命令行能连上的仓库插件不一定连得上反过来也一样。版本要锁。SVN 客户端版本比服务端高一到两个小版本通常没事但工作副本格式是单向升级的命令行 svn 1.8 只要对该目录执行过一次写操作工作副本就会被升级到 1.8 格式此后 site-1.8.22 这套插件就再也读不了它。所以在同一台机器上命令行 svn 和插件支持的格式版本必须保持一致。2.4 查清已有工作副本的格式别轻易升级接手别人的工作目录时第一件事不是检出是看格式。# 工作副本格式号存在 wc.db 里1.7 之后都是 SQLite 数据库 cd /data/workspace/legacy-project sqlite3 .svn/wc.db PRAGMA user_version;这个数字对应关系大致是10 对应 1.6 格式29 对应 1.7 格式31 对应 1.8 及以后。读到 29 说明还在 site-1.8.22 的处理范围内读到 31 就要停一下了这套插件很可能打不开它强行打开会提示工作副本格式过新。如果确实需要升级格式命令是svn upgrade但这个操作没有后悔药# 升级前先备份整个工作副本升级是不可逆的 cp -a /data/workspace/legacy-project /data/backup/legacy-project-$(date %Y%m%d) # 执行升级只升级格式不动文件内容 svn upgrade /data/workspace/legacy-project # 升级后确认格式号变化 sqlite3 /data/workspace/legacy-project/.svn/wc.db PRAGMA user_version;升级完成之后旧版客户端和旧版插件就彻底进不去了团队里只要还有一个人在 Eclipse 里用 site-1.8.22你这一升就等于把他踢出协作。所以升级前先问清楚所有人用的插件版本这一步比备份还重要。3. 三种装法把 site-1.8.22 塞进 Eclipse 的具体步骤site 包本质上是一个离线更新站点解压后能看到 features、plugins 两个目录以及一个 site.xml。三种装法对应三种场景能打开 Eclipse 界面时用本地站点安装最稳批量铺机器时用 dropins 或 links 更省事。先把包解开、看清结构再决定用哪种。# 先看压缩包里到底有什么别急着解压 unzip -l site-1.8.22.zip | head -20 # 典型输出里应该能看到这些 # features/ # plugins/ # site.xml # content.jar # artifacts.jar有 site.xml 说明它是老式更新站点Eclipse 4.x 仍然认有 content.jar 和 artifacts.jar 说明它同时被包装成了 p2 仓库两种方式都能读。看清之后再决定解压到哪。# 统一放到一个插件仓库目录后面三种装法都从这里取 sudo mkdir -p /opt/eclipse-plugins sudo unzip -q site-1.8.22.zip -d /opt/eclipse-plugins/svn-1.8.22 # 确认解压结果的层级features 和 plugins 必须直接在这一层 ls /opt/eclipse-plugins/svn-1.8.22这一步用ls确认层级是整篇文章里最便宜也最有效的一次检查。第 1 章开头那个坑就是多套了一层site-1.8.22/site-1.8.22/featuresEclipse 扫不到装完什么也没发生。3.1 方式一从本地站点安装可控性最好能进图形界面就优先用这个方式因为它会把安装记录写进 p2 的 profile卸载干净、升级路径清晰。操作路径是 Help Install New Software Add Local选中/opt/eclipse-plugins/svn-1.8.22这一层目录注意别选到 features 里面去。列表里会列出可装的组件勾选 SVN Team Provider 一类的条目一路 Next接受协议最后重启。如果在 Add 的对话框里选择 Archive 直接指向 zip也行。区别在于 Archive 方式每次重装都要重新解压一遍Local 方式指向的是已解压目录后面改配置或者打补丁更方便。装完先别急着用做一次清理启动# -clean 会重建插件的注册缓存-consoleLog 把日志打到控制台方便看 $ECLIPSE_HOME/eclipse -clean -consoleLog -nosplash-clean只影响插件缓存不动工作空间和代码可以放心加。-consoleLog在有问题的机器上一定要带很多加载失败只在这行输出里露出真话。3.2 方式二dropins 目录解包安装适合批量铺机器dropins 是 Eclipse 给免安装式插件留的口子把 features 和 plugins 按约定摆进去就行。前提是目录层级必须严格dropins 下面那层可以是任意名字的文件夹但再往下必须直接是 features 和 plugins。# 建一个独立子目录名字随意但不能直接平铺文件 mkdir -p $ECLIPSE_HOME/dropins/svn-1.8.22 # 把两个目录整体拷进去注意是拷目录本身不是拷目录里的内容 cp -r /opt/eclipse-plugins/svn-1.8.22/features $ECLIPSE_HOME/dropins/svn-1.8.22/ cp -r /opt/eclipse-plugins/svn-1.8.22/plugins $ECLIPSE_HOME/dropins/svn-1.8.22/ # 检查结果这两个路径必须都存在 ls $ECLIPSE_HOME/dropins/svn-1.8.22拷完之后同样要带-clean启动一次。Eclipse 4.x 对 dropins 的支持还在但行为比 3.x 严格带 jar 的插件包要保证 MANIFEST 里声明了正确的 Bundle-SymbolicName不然扫描时会被静默跳过。这也是为什么很多人反馈dropins 放了没反应其实不是没扫是扫到了但被判定为无效。要卸载的时候直接把dropins/svn-1.8.22整个删掉再-clean启动一次就干净了。这一点比方式一省心适合一次性铺十几台构建机的场景。3.3 方式三links 挂载多套 Eclipse 共用一份插件一台机器上装了两三个 Eclipse做兼容性验证时很常见的时候dropins 的写法要重复好几份占空间还容易版本不一致。links 方式能把插件放在公共目录让多个 Eclipse 实例共享同一份。# 文件路径为 $ECLIPSE_HOME/links/svn-1.8.22.link # 内容只有一行指向插件根目录含 features 和 plugins 的那一层 path/opt/eclipse-plugins/svn-1.8.22Windows 上路径要写双反斜杠且不要写成单个反斜杠也不要在等号后面加空格pathD:\\eclipse-plugins\\svn-1.8.22.link文件的扩展名必须是 link内容里 path 后面跟的必须是绝对路径。写完同样要-clean启动一次否则 Eclipse 不会重新扫描 links 目录。这个方式的另一个好处是插件目录和 Eclipse 安装目录彻底分离Eclipse 升级覆盖安装时插件不受影响。3.4 装完先验证插件有没有被真正加载三种方式装完都要先做一次加载验证再谈配置。验证方法是从 Help About Eclipse Installation Details Plugins 页签里搜关键词或者直接看 configuration 目录下的日志# 安装细节里的已装插件列表是最直接的证据 grep -i svn $ECLIPSE_HOME/configuration/*.log | tail -20日志里如果出现 version 冲突、Missing Constraint、requires bundle 之类的字样说明插件依赖没满足多半是 Eclipse 版本偏高或偏低这时候继续往下配 SVN 接口是浪费时间先把版本对齐。4. 配置 SVN 接口JavaHL 与 SVNKit 怎么选、路径怎么写插件装上了Team 菜单里也出现了 SVN但第一次点检出就报 Unable to load default SVN Client这是第二道坎。根因几乎都在 SVN 接口这一层插件自己有界面真正干活的底层实现有三种选错了或者路径没配对界面上一切正常操作时全失败。4.1 三种接口的取舍接口依赖适合场景主要短板JavaHL本地 JavaHL 库随 SVN 客户端提供需要完整语义文件锁、属性操作要求严格架构和路径必须完全对上配错就没法用SVNKit纯 Java无本地库跨平台、临时机器、不想折腾本地库个别高级特性支持不完整命令行客户端本机 svn 可执行文件已经装了命令行 svn想复用同一套认证每次操作起一个进程速度偏慢我的默认选择是长期使用的开发机、构建机配 JavaHL临时排障、虚拟机快照、不想装本地库的场景切 SVNKit已经有稳定的命令行 svn 并且团队习惯一致的环境用命令行接口最省心。切换位置在 Window Preferences Team SVNSVN Interface 一栏的 Client 下拉里。下拉里如果只显示 SVNKit说明 JavaHL 没被加载成功此时不用改别的先去解决本地库。4.2 JavaHL 的 java.library.path 配置JavaHL 是一个 JNI 桥Eclipse 启动时要去java.library.path里找本地库文件。Windows 上是svnjavahl-1.dllLinux 上是libsvnjavahl-1.so。找不到下拉里就只有 SVNKit。最稳的做法是把路径写进 eclipse.ini而不是靠系统环境变量因为很多机器上 PATH 是给命令行用的GUI 程序继承不到。# eclipse.ini 关键片段注意顺序 -vm C:/Java/jdk1.8.0_201/bin/javaw.exe -vmargs -Dosgi.requiredJavaVersion1.8 -Xms512m -Xmx1024m -Djava.library.pathC:/Program Files/TortoiseSVN/bin;C:/Windows/System32几个参数必须说清楚-vm必须写在-vmargs之前而且要单独占一行下一行写完整路径路径里不要加引号。写在-vmargs之后的话 Eclipse 会把它当成 JVM 参数传给 Java直接启动失败。-Djava.library.path在 Windows 上多个路径用分号分隔Linux 上用冒号。路径里带空格是可以的但整行不要加引号加了反而会被当成路径的一部分。-Xmx别调太小。SVN 检出大仓库时插件会把变更列表读进内存堆不够会在检出中途抛 OutOfMemory表现却像网络超时很难查。Linux 上的写法-vmargs -Dosgi.requiredJavaVersion1.8 -Xms512m -Xmx1024m -Djava.library.path/usr/lib/jni:/usr/lib/x86_64-linux-gnu/jni/usr/lib/jni是 Debian 系 libsvn-java 包安装本地库的默认位置RHEL 系一般装在/usr/lib64。装完包先确认库文件在哪再写进 ini不要凭记忆写路径# 找到 libsvn-javahl 的实际位置以实际输出为准 find /usr -name libsvnjavahl* 2/dev/null改完 eclipse.ini 一定要带-clean重启。如果下拉里能选到 JavaHL 并显示版本号说明这一层通了。4.3 SVNKit 的适用边界SVNKit 是纯 Java 实现不需要本地库也不用管 32/64 位切过去就能用。它的短板在一些边界操作上工作副本的锁定语义、部分属性递归操作、以及和服务端版本的兼容性偶尔会和 JavaHL 表现不一致。遇到某人能提交某人不能提交这种玄学问题时第一件事就是让两个人把 SVN Interface 统一下来。同一个团队里一半 JavaHL 一半 SVNKit是最容易出现我这边好好的这类无解对话的配置。4.4 认证缓存、忽略列表和行尾符接口选好之后有三项配置建议一次性配到位省得后面反复改。认证缓存位置跟随命令行客户端不跟随插件# Linux/macOS ls ~/.subversion/auth/svn.simple/ # Windows 在 %APPDATA%\Subversion\auth改过密码之后插件一直报认证失败八成是这里存着旧凭据。把auth目录整个删掉下次操作会重新提示输入比重启 Eclipse 有效得多。忽略列表在 Preferences Team Ignored Resources 里维护和.gitignore类似但语法弱得多只支持通配符。项目级的忽略规则还是老老实实用svn:ignore属性属性会跟着仓库走团队里所有人一致。行尾符的问题在混合操作系统团队里几乎必然出现。配置在客户端的 config 文件里# ~/.subversion/configWindows 为 %APPDATA%\Subversion\config [miscellany] enable-auto-props yes [auto-props] *.java svn:eol-stylenative *.xml svn:eol-stylenative *.properties svn:eol-stylenative *.sh svn:eol-styleLF;svn:executable *.bat svn:eol-styleCRLFenable-auto-props是总开关不开的话下面这段全部无效。native表示按当前操作系统自动转换检出到 Windows 是 CRLF检出到 Linux 是 LF。svn:executable只对脚本有意义作用是保留可执行位不加的话从 Windows 提交上去的 shell 脚本在 Linux 上拉下来没有执行权限。这两行配置能省掉大量文件内容一样但 diff 一片红的排查时间。5. 排查装 site-1.8.22 最容易翻车的五个地方前面几章的步骤走对了大部分机器能一次通。剩下那部分机器问题基本集中在下面五类。每条按现象、原因、解决三段来看能省掉很多瞎试的时间。5.1 现象插件放进 dropins 重启后毫无反应原因九成是目录层级错。dropins 下面允许有一层任意命名的文件夹但再往下必须直接是 features 和 plugins如果解压时多套了一层svn-1.8.22/svn-1.8.22/Eclipse 扫描到这一层找不到清单文件就静默跳过了不报错。解决先ls确认层级把多出来的那层去掉确认无误后带-clean重启。如果还是不生效看configuration/*.log那里会有被跳过的插件清单和原因。5.2 现象Preferences 里只有 SVNKit选不到 JavaHL原因本地库没被找到或者位数不匹配。64 位 Eclipse 加载 32 位 dll 只会给一句很模糊的失败日志里也不一定写全。解决先用java -XshowSettings:properties -version确认 JVM 位数再确认本地库位数一致然后用find定位库文件真实路径写进 eclipse.ini 的-Djava.library.path。改完-clean重启。实在对不上先切 SVNKit 把活干完再回头收拾 JavaHL不要卡在这一步上耽误进度。5.3 现象检出时报工作副本格式过新或过旧原因工作副本格式和插件支持的格式不匹配。过新是别的客户端升过格式过旧是仓库里留着很久以前的工作副本。解决先查格式号再决定方向。过新只能用新版客户端处理或者换更新的插件分支过旧执行svn upgrade但升级前必须备份并通知团队因为升级不可逆。这条坑的血泪经验是不要在没有备份的情况下对别人的工作目录执行任何写操作包括看起来无害的svn update。5.4 现象中文路径或提交信息乱码原因工作空间编码、JVM 默认编码、系统 locale 三者不一致。Eclipse 默认用平台编码Windows 中文环境是 GBK提交到服务端就成了乱码。解决在 eclipse.ini 的-vmargs后面加-Dfile.encodingUTF-8同时在 Preferences General Workspace 里把 Text file encoding 设成 UTF-8。两台机器都要改只改一台等于没改。改完重启历史提交信息里的乱码不会自动修复但新提交会正常。5.5 现象提交卡住、目录被锁、cleanup 也解不开原因.svn/wc.db被别的进程占着最常见的是文件索引服务、杀毒软件实时扫描或者上一次操作中途断网留下的残留锁。解决先关掉所有占用该目录的程序包括另一个 Eclipse 实例和资源管理器的预览然后执行svn cleanup勾选 Break locks如果仍然无效把改动过的文件复制出来重新检出一份干净的工作副本再把文件覆盖回去。最后这一步看起来笨但在锁状态彻底坏掉的情况下比重装服务器快得多。6. 验证跑通一次检出、改一行、提交、再还原装完不做验证等于没装。我习惯用一条完整的最小闭环来验收从仓库检出到本地改一行提交上去再从历史里查回来最后还原本地改动。这五步覆盖了认证、读、写、历史查询和本地回滚任何一层没配对都会在这个闭环里暴露。验证项操作或命令期望结果仓库连接SVN Repository Exploring 透视图添加仓库地址能展开 trunk、branches、tags检出右键仓库目录 Checkout选工作空间路径本地出现完整目录无报错状态识别右键项目 Team Show SVN Annotate 或查看图标文件夹上有版本标记无问号提交改一行文件 Team Commit提交成功文件图标恢复干净状态历史查询Team Show History能看到刚才那条提交记录本机还原再改一行 Team Revert改动被丢弃文件回到上次提交状态命令行交叉验证svn status/svn log -l 3输出与图形界面一致无锁、无冲突命令行交叉验证这一步值得单独强调它是判断到底是插件问题还是工作副本问题的分水岭# 进入刚才用插件检出出来的目录 cd /data/workspace/legacy-project # status 第一列是本地改动标记第二列是属性标记没有任何输出说明工作副本干净 svn status # 只看最近三条提交确认插件提交的记录在服务端确实存在 svn log -l 3 # 用命令行再提交一次验证认证缓存和插件用的是不是同一套凭据 echo verify README.md svn commit -m verify from cli README.md如果图形界面报错但命令行正常问题一定在插件这一侧回到第 4 章查接口和路径如果两边都报错问题在工作副本或服务端跟插件版本没关系。这条判断路径能省掉大量来回折腾。svn status的输出约定要记住第一列M是内容被改A是新增D是删除第二列M是属性被改?是未纳入版本控制L是被锁。看到L就按 5.5 处理别硬提交。还有一个容易被忽略的验证点换一台机器重新走一遍检出。插件的问题经常带环境依赖在你机器上好好的到同事机器上就加载失败。所以我每次装完都会把 eclipse.ini 的关键段落和插件目录结构一起记进部署文档让第二个人照着文档独立装一遍装不通就说明文档缺东西。从那以后我每次给新机器装这套环境都会强制先跑一遍查 Eclipse 版本、查 JVM 位数、查命令行 SVN 版本、查工作副本格式这四查再动手解压插件包最后用检出加提交的闭环收尾一套走完才把机器交付出去。前面省下的每一步后面都会以两倍的时间还回来。希望帮到你。这份 site-1.8.22 的离线包和随包带的安装说明我已经放在下载区按上面第 3 章三种装法里挑一种对应你机器的配完回来跑一遍第 6 章的闭环就算装好了。本文还有配套的精品资源点击获取