企业官网建设流程全解析

简介：面向需要在 MyEclipse/Eclipse 中集成 SVN 的 Java 开发者，这份 site-1.8.22 插件包提供 Subclipse 1.8.x 稳定版组件及安装说明，主要解决 IDE 内代码提交、更新、历史查看与冲突处理等版本控制需求。压缩包共 30 个文件，约 16.9MB，以 27 个 jar 组件为主，另含 docx 安装文档、site.xml 更新站点描述和 html 帮助入口，兼顾离线安装与在线站点配置。已有 940 人学习下载，适合不熟悉插件源配置或需要为旧版 MyEclipse 补齐 SVN 支持的开发者参考。其价值在于把客户端适配器、图形化日志、合并工具和文档说明打包在一起，读者可据此完成环境集成，并在日常开发中使用提交、更新、差异对比、版本浏览、回滚与冲突解决等功能，减少在 IDE 与命令行之间来回切换的成本。

1. SVN 插件 site-1.8.22 离线包到底解决什么问题

手里只有一个 svn插件 site-1.8.22 压缩包，外加一份 svn安装说明，目标机器在内网，宿主 IDE 又不让联网，这种场景最考验离线包的落地能力。site-1.8.22 不是单个 jar，而是一个按更新站点（site）格式组织的插件仓库，安装向导从里面读 features、plugins 和索引文件，把 SVN 团队提供程序装进 IDE。它解决的是“不能访问外网更新站点、又要把 SVN 版本控制接进 IDE”的问题，适合内网开发机、老版本 IDE 维护、以及需要固定插件版本的交付环境。 很多人拿到包直接双击安装，结果安装向导报 no repository found，问题往往不在包本身，而在压缩包多了一层目录，或者安装说明里没写清连接器要单独配。下面按“先拆包核对结构，再装 Team Provider，最后配连接器和排查”的顺序走，新手能照着复现，熟手也能看到版本匹配和证书信任的边界。

2. 拆开 site-1.8.22：目录结构、版本匹配与安装前检查

拿到 site-1.8.22 压缩包，先别急着打开 IDE 的安装向导。site 包本质是一个本地更新站点，安装向导只认“根目录下直接有 content.jar、artifacts.jar、features、plugins”的结构。如果压缩包解开后先看到一层同名文件夹，安装向导就会把这一层当成仓库根，读不到索引，最后报 no repository found。这个坑很常见，尤其是从聊天工具或邮件附件里转存过的压缩包，解压工具会自动多建一层目录。先解压、再看结构，比在安装向导里反复重试省时间。

2.1 site 包不是普通插件 jar：先认清 features/plugins 与两个索引文件

site 包的结构不复杂，但每个文件都有明确分工。content.jar 描述“有哪些可安装单元”，artifacts.jar 描述“构件在仓库里的相对位置”，features 目录放功能分组，plugins 目录放实际插件 jar。安装向导先读索引，再按索引去 plugins 里取包，所以缺一个索引文件都可能让安装列表为空。下面这张表是拆包后首先要核对的几个位置。

拆包时用命令行看层级最直接，避免图形界面隐藏文件。下面这段命令只做三件事：进入解压目录、看根目录、找 features 和 plugins 的实际深度。

# 进入解压后的 site 目录，检查更新站点根结构 cd /path/to/site-1.8.22 ls -la # 期望直接看到 content.jar、artifacts.jar、features、plugins # 如果只看到一层 site-1.8.22/，说明压缩包多包了一层 find . -maxdepth 2 -type d \( -name features -o -name plugins \) -print

cd后面的路径按实际解压位置替换；ls -la用来确认根目录有没有 content.jar 和 artifacts.jar；find的-maxdepth 2限制只往下看两层，避免在深层插件目录里刷屏。如果输出显示 features 和 plugins 在./site-1.8.22/features这种层级，说明安装源要选内层目录，而不是最外层。此时要么重新解压并选择“解压到当前目录”，要么在安装向导里用 Local 方式直接指向包含 content.jar 的那一层。

注意：site 包 zip 的根目录必须直接看到 features 和 plugins，多一层文件夹安装向导会读不到。

除了目录层级，还要看索引文件是否完整。有些包在传输过程中只丢了 content.jar，安装向导仍然能打开，但可勾选列表是空的。用解压工具打开 content.jar，里面通常能看到若干 xml 描述；如果打不开，先重新拿包，不要继续安装。安装说明里如果写了“选择 SVN Team Provider”，但列表里只有连接器没有 Team Provider，也说明这个 site 包不是完整站点，或者你选错了层级。

2.2 版本匹配：插件版本、连接器版本、工作副本格式别混着看

site-1.8.22 里的 1.8.22 是插件发布版本号，不是 SVN 服务端版本号，也不是工作副本格式号。很多人在安装说明里看到 1.8.22，就以为服务端也必须是 1.8.22，结果在选连接器时反复换包。实际关系是：Team Provider 负责把 SVN 操作接进 IDE，连接器负责真正跟服务端通信和管理工作副本；插件版本、连接器版本、服务端协议版本、工作副本格式是四件事。选型时先看宿主 IDE 能装哪个主版本的 Team Provider，再看安装说明指定的连接器主版本，最后确认现有工作副本是不是高版本客户端创建的。

工作副本格式是最容易被忽略的一项。高版本 SVN 客户端创建的工作副本，低版本连接器可能直接报“working copy is too old”或“too new”。在命令行里用svn info看工作副本根和格式，比在 IDE 里猜更稳。下面这段命令用来对照命令行客户端和工作副本信息。

# 查看当前命令行 SVN 客户端版本与工作副本格式 svn --version --quiet svn info /path/to/working-copy | sed -n '1,12p' # 查看 IDE 使用的 Java 版本（不同 IDE 启动脚本不同，按实际替换） "$IDE_HOME/ide" -vmargs -version 2>/dev/null || java -version

svn --version --quiet只输出版本号，方便跟安装说明对照；svn info看工作副本根路径、URL 和格式相关信息，sed -n '1,12p'只取前十几行，避免输出太长；最后一条命令在部分 IDE 上不一定支持-version，更稳妥的做法是打开 IDE 的 About 或 Installation Details，看它运行的 Java 版本。参数不用死记，关键是别把“插件版本 1.8.22”直接当成“服务端必须 1.8.22”，否则会在选连接器时走弯路。

Java 版本也要提前看。Team Provider 和连接器都是 Java 插件，如果插件编译目标版本高于 IDE 运行 JDK，启动时会报 UnsupportedClassVersionError，表现可能是 SVN 视图打不开，也可能是 IDE 启动到一半卡住。安装前记录 IDE 当前使用的 JDK 路径，安装后用同一个 JDK 启动，不要一会儿用系统默认 Java，一会儿用 IDE 自带 Java。版本匹配没有玄学，靠的是把“IDE 主版本、运行 JDK、Team Provider 主版本、连接器主版本、工作副本格式”五项写在纸上，再决定装哪个包。

2.3 安装前检查清单：Java、宿主 IDE、旧插件与权限

安装前最值得做的是备份和清理。备份宿主 IDE 的 configuration 目录和当前 workspace，出问题能回退；清理 dropins 里旧版本的 SVN 插件，避免新旧版本同时被扫描。很多人装完发现 Team 菜单出现两个 SVN 选项，或者提交时类冲突，根子就是 dropins 里还躺着旧插件。下面这张检查表按“先看什么、通过标准是什么”列，适合安装前过一遍。

用命令行找旧插件和做备份比较快。下面这段命令在 IDE 安装目录下查找名字里带 svn 的目录或 jar，并备份 configuration。

# 在 IDE 安装目录下查找可能冲突的旧 SVN 插件 find "$IDE_HOME" -maxdepth 3 \( -iname '*svn*' -o -iname '*subversive*' \) -print # 备份 configuration 目录，出问题可回退 cp -a "$IDE_HOME/configuration" "$IDE_HOME/configuration.bak"

$IDE_HOME换成实际安装目录；find的-maxdepth 3控制搜索深度，-iname忽略大小写，*svn*和*subversive*是两个常见关键词；cp -a保留权限和时间戳做完整备份。找到旧插件后不要直接删，先移到备份目录，确认新插件能用再清理。安装目录没有写权限时，安装向导可能显示成功但重启后插件消失，这种“假成功”多半是权限问题。

提示：安装向导里的“Contact all update sites”在内网环境要取消，否则会卡在联网检查。

安装前还要确认磁盘空间和路径。site 包解压后路径不要带空格和中文，Local 安装源尤其如此；路径带空格时，某些启动脚本会把参数截断。workspace 也建议用独立目录做测试，不要拿正在交付的 workspace 直接试装。做完这些检查，再进安装向导，后面遇到问题才有对照物。

3. 把插件装进 IDE：Archive/Local 两种装法与连接器配置

安装向导只认更新站点，不认随便一个压缩包。site-1.8.22 有两种常用装法：Archive 方式直接把 zip 喂给安装向导，适合压缩包根目录正确的情况；Local 方式先解压再选目录，适合排查多一层文件夹、或者需要把安装源固定到共享目录的情况。两种方式都不要用“把 jar 拷进 dropins”的土办法，dropins 不处理依赖和索引，装完容易出现菜单有了但连接器为空。安装时先取消自动联网更新站点，内网环境里这个选项会让向导卡很久。

3.1 Archive 安装：把 site 压缩包直接喂给安装向导

Archive 安装的步骤不复杂，关键是选对包和取消联网检查。打开宿主 IDE 的 Help -> Install New Software，点 Add，选择 Archive，指向 site-1.8.22 压缩包；安装向导会读包里的 content.jar 和 artifacts.jar，然后列出可安装项。此时只勾选 SVN Team Provider 相关功能，不要全选连接器和其他可选组件，连接器后面单独配。点下一步接受许可，安装完成后重启 IDE。整个过程不要勾选 Contact all update sites，内网环境里它会让向导去访问不存在的更新站点。

安装完成后第一次启动建议带-clean参数，让插件平台重新扫描插件缓存。下面这段命令演示启动方式，路径按实际 IDE 安装目录替换。

# 安装完成后带 -clean 启动一次，清掉旧的插件缓存 "$IDE_HOME/ide" -clean # 如果 IDE 需要显式指定 JDK，用 -vm 指向 bin/java "$IDE_HOME/ide" -clean -vm "/path/to/jdk/bin/java"

-clean的作用是让平台重新计算插件注册表，安装或卸载插件后建议走一次；-vm用来指定 IDE 运行 JDK，路径要指向 JDK 的bin/java，不是 JRE 目录。-clean只建议在安装后或排错时用，日常启动不需要每次加。如果启动脚本不支持这些参数，就在快捷方式或启动配置里加，不要直接改插件目录。Archive 方式报 no repository found 时，先回到第 2 章检查 zip 根目录，不要反复换安装向导版本。

Archive 安装还有一个细节：安装向导里勾选的 feature 名称可能和安装说明不完全一致。安装说明写“SVN Team Provider”，列表里可能显示为带版本号的功能名，或者把 Team Provider 和连接器分成两组。此时看功能描述里有没有 Team Provider 关键词，不要只认一个名字。安装完成后在 Installation Details 里搜索 svn，能看到已安装 feature 的版本号，和 site 包目录里的 feature 版本对一下，能确认装的是不是同一套。

3.2 Local 安装：解压目录方式与多版本隔离

Local 安装适合两种场景：压缩包多了一层目录，Archive 方式读不到；或者团队要把安装源放到共享目录，多台机器复用。做法是先解压到固定路径，再在安装向导里 Add -> Local，指向包含 content.jar 的那一层。解压路径不要带空格和中文，多版本要分目录存放，比如 site-1.8.22 一个目录，连接器包另一个目录，避免安装向导把两个版本的 feature 混在一起读。下面这段命令建独立目录并定位 content.jar 的层级。

# 建独立仓库目录并解压，避免路径带空格 mkdir -p /opt/site-repo/site-1.8.22 unzip -q /path/to/site-1.8.22.zip -d /opt/site-repo/site-1.8.22 # 如果解压后多了一层，把内层作为 Local 安装源 find /opt/site-repo/site-1.8.22 -maxdepth 2 -name content.jar -print

mkdir -p建目录并忽略已存在；unzip -q静默解压，减少输出干扰；find用-maxdepth 2找 content.jar，输出路径的上一级就是 Local 要选的目录。如果输出是/opt/site-repo/site-1.8.22/site-1.8.22/content.jar，Local 就选内层site-1.8.22目录。多版本隔离的意义在于排错时能确定“当前安装源到底是哪一版”，不会出现安装列表里同时出现两个版本、勾错一个的情况。

Local 安装完成后同样要重启并检查 Installation Details。如果安装列表为空，先看 Local 指向的目录下有没有 content.jar，再看 content.jar 能不能正常打开。有些解压工具会把 jar 当压缩包再解一层，导致目录里出现content.jar文件夹而不是文件，安装向导读不到。遇到这种情况，重新解压并确认文件类型。Local 方式的好处是安装源可以固定下来，后面换机器或重建 workspace 时不用再找压缩包。

3.3 连接器不是可选件：SVN Interface 配置与重启参数

Team Provider 装完不等于 SVN 能用。打开 Preferences -> Team -> SVN，看 SVN Interface 下拉框；如果为空，说明连接器没装，或者连接器 feature 没被加载。常见连接器有 SVNKit 和 JavaHL 两类，SVNKit 是纯 Java 实现，离线部署时依赖少；JavaHL 依赖本地库，跨平台时要额外带动态库。安装说明里如果指定了连接器，就按说明装同一主版本；没有指定时，优先选纯 Java 连接器，减少本地库缺失的排查成本。不要同时装多个连接器版本，IDE 里可能出现接口冲突。

连接器装完后回到 SVN Interface 下拉框选中它，再配置超时、字符集和证书信任。字符集影响中文文件名和提交注释，IDE 的文本编码、workspace 编码、SVN 配置里的编码要一致。证书信任是内网 SVN 服务端最常见的问题：自签 CA 没导入 IDE 所用 JDK 的信任库时，连接会报 PKIX path building failed 或 certificate unknown。下面这段命令把 CA 证书导入 JDK 信任库，并验证别名是否存在。

# 将内网 SVN 服务端的 CA 证书导入 IDE 所用 JDK 的信任库 keytool -importcert -alias svn-ca -file /path/to/svn-ca.crt \ -keystore "$JAVA_HOME/lib/security/cacerts" -storepass changeit # 查看信任库中是否已有别名 keytool -list -keystore "$JAVA_HOME/lib/security/cacerts" -storepass changeit | grep svn-ca

-alias是信任库里的唯一别名，别和已有别名重复；-file指向 CA 证书，不是服务端私钥；-keystore必须指向 IDE 实际使用的 JDK，不是系统默认 Java；changeit是默认口令，改过就换成实际口令；keytool -list加grep用来确认导入成功。证书导入后重启 IDE，不要用关闭证书校验的方式绕过，关闭校验只能让当前连接通过，换机器或换 workspace 还会再犯。

注意：连接器装完仍看不到 SVN Interface 时，先看 Installation Details 里连接器 feature 是否存在，再带-clean重启，不要直接删 workspace。

配置完成后做一次最小验证：新建一个 SVN 资源库位置，填内网仓库地址，看能否列出分支目录；再找一个空目录做 checkout，确认工作副本能创建。不要拿正在开发的工作副本直接试，证书或连接器问题可能在提交时才暴露。连接器配置是 site-1.8.22 落地里最容易被跳过的一步，安装说明如果只写了“安装插件”，多半还要补连接器这一段。

4. 安装后连不上、菜单不出现：五类高频翻车现场排查

安装向导显示成功，不等于 SVN 能用。翻车点通常集中在五处：site 包结构不对、连接器没装、Java 版本不匹配、证书不受信任、工作副本格式不兼容。排查时先看三个地方：Installation Details 里有没有对应 feature，workspace 的.metadata/.log里有没有 SVN 异常，Preferences 的 SVN Interface 下拉框是不是空的。血泪经验是先把 workspace 和 configuration 备份好再动，不要一上来删 workspace，删完问题没解决，本地未提交的改动也找不回来。

4.1 先看三个地方：安装详情、错误日志、SVN Interface 下拉框

排查顺序比工具更重要。先确认插件到底装没装：Installation Details 里搜 svn，看 Team Provider 和连接器的 feature 版本；再看 SVN Interface 下拉框，空的话优先怀疑连接器；最后看日志，日志里通常有异常类名和仓库地址。下面这张表把常见症状和第一检查点对上，避免在安装向导里反复重装。

日志位置随 IDE 不同略有差异，但 workspace 下的.metadata/.log是通用入口。下面这段命令抓 SVN 相关异常和启动日志。

# 在 workspace 的 .metadata 日志里抓 SVN 相关异常 grep -iE 'svn|subversive|svnkit|UnsupportedClassVersion|No repository' \ "$WORKSPACE/.metadata/.log" | tail -n 80 # 如果 IDE 启动不了，查 configuration 下的日志 find "$IDE_HOME/configuration" -maxdepth 2 -name '*.log' -print

$WORKSPACE换成实际 workspace 路径；grep -iE忽略大小写并一次匹配多个关键词；tail -n 80只看最近 80 行，避免日志太长；find用来找启动日志，-maxdepth 2控制深度。日志里如果出现No repository found，回到第 2 章看 site 包结构；出现UnsupportedClassVersionError，看 Java 版本；出现PKIX或certificate，看证书信任库。先定位再动手，比盲目重装快。

4.2 五条踩坑记录：现象、原因、解决

第一条是 Archive 安装报 No repository found。现象是安装向导选完 zip 后，列表出不来，或者弹窗提示找不到仓库。原因通常是 zip 多了一层目录，content.jar 和 artifacts.jar 不在安装源根目录；也可能是压缩包只含 plugins 不含 features，根本不是完整 site 包。解决方法是解压后用find找 content.jar，把包含它的那一层作为 Local 安装源；如果找不到 content.jar，换完整离线包，不要继续在 Archive 里重试。

第二条是安装成功但 Team 菜单没有 SVN。现象是重启后右键 Team 里没有 Share Project，Preferences 里 SVN Interface 下拉框为空。原因多半是只装了 Team Provider，没装连接器；也可能是连接器 feature 装了但没被加载。解决方法是回到安装源勾选连接器 feature，装完带-clean重启；如果安装说明里连接器在另一个包，按说明补装，不要混装多个版本。装完再看下拉框，选中连接器再连仓库。

第三条是启动报 UnsupportedClassVersionError，或者打开 SVN 视图卡死。现象是日志里出现Unsupported major.minor version，插件类加载失败。原因是插件编译目标 JDK 高于 IDE 运行 JDK，常见于换了启动脚本、系统默认 Java 变了、或者 IDE 快捷方式里写死了旧 JDK。解决方法是用-vm显式指定与插件匹配的 JDK，确认 About 里显示的 Java 版本和安装说明一致；如果 IDE 主版本太老，换对应版本的 site 包，不要硬升 JDK 后又遇到插件 API 不兼容。

第四条是连接仓库报 PKIX path building failed 或 certificate unknown。现象是能打开 SVN 资源库视图，但一连内网地址就报证书错误。原因是内网 SVN 服务端用自签 CA，IDE 所用 JDK 的 cacerts 里没有这张证书；也可能是证书主机名和仓库地址不一致。解决方法是用 keytool 把 CA 证书导入 IDE 实际使用的 JDK 信任库，确认别名唯一，重启 IDE；主机名不一致时换用证书里的主机名访问，不要关闭证书校验。

第五条是提交报 Working copy is too old 或 locked。现象是 checkout 正常，提交或更新时报工作副本格式不兼容，或者提示某路径被锁。原因是工作副本由更高版本客户端创建，当前连接器版本低；或者上次提交中断留下锁。解决方法是先看svn info的工作副本格式，能升级连接器就升级，不能升级就重新 checkout 到新目录；锁的问题先跑svn cleanup，不要手删.svn目录，手删会把工作副本元数据一起破坏。

注意：不要手删工作副本里的 .svn 目录，锁和格式问题先走 svn cleanup 或重新 checkout。

这五条里，前两条是安装阶段问题，后三条是运行阶段问题。排查时按“安装详情 -> 下拉框 -> 日志 -> 证书 -> 工作副本”的顺序走，基本能覆盖 site-1.8.22 落地时的高频翻车。安装说明里如果只写了安装步骤没写连接器，第四条和第五条尤其容易漏；把连接器版本和工作副本格式记在安装记录里，下次换机器能少走很多弯路。

5. 验证与长期维护：用命令行对照插件行为，别让环境漂移

装完不要只看菜单里有没有 SVN，做三步验证更踏实。第一步在 Installation Details 里搜 svn，确认 Team Provider 和连接器 feature 都在；第二步看 Preferences -> Team -> SVN 的 SVN Interface 下拉框，选中连接器；第三步新建一个空目录做 checkout，提交一个小文本文件，再用命令行svn info和svn status对照。命令行能看到 URL、Revision 和本地改动，IDE 里如果显示不一致，优先怀疑连接器或工作副本格式，而不是仓库本身。

# 命令行对照：确认工作副本格式和远端地址 svn info /path/to/working-copy | grep -E 'URL|Revision|Working Copy Root Path' # 小文件提交后再查一次，确认插件没有静默失败 svn status /path/to/working-copy

svn info的grep只取 URL、Revision 和工作副本根，方便跟 IDE 里显示的信息对照；svn status看本地改动，IDE 显示提交成功但命令行仍有改动，说明提交没有真正落库或者提交到了别的路径。参数不用改，关键是固定用同一个命令行客户端做对照，别一会儿用系统自带 SVN，一会儿用 IDE 内置连接器。

长期维护上，我习惯把 site-1.8.22 压缩包、安装说明、连接器包放在同一个归档目录，目录名带版本号，安装记录里写清 IDE 主版本、运行 JDK、连接器版本和工作副本格式。测试新插件用独立 workspace，不要拿交付中的 workspace 直接试。从那以后，我每次拿到这种 site 包，都先解压核对 content.jar 和 features 目录，再进 IDE 安装，宁可多花五分钟，也不在客户现场找后悔药。如果你手里的 site-1.8.22 解压后没有 content.jar，先别装，找完整离线站点包；安装说明和包放一起归档，下次换机器能直接复现。希望帮到你。

本文还有配套的精品资源，点击获取