Navicat本身不支持SVN集成，其“版本控制”仅限本地历史记录或备份快照；数据库模型文件（如.nmmp、.sql）需通过TortoiseSVN等外部工具手动提交、更新和回滚，且二进制文件易冲突，建议导出为可读SQL脚本纳入SVN管理。
Navicat 本身不支持 SVN 集成
navicat 没有内置 svn 客户端，也不能将数据库模型（如 model 文件）直接提交、更新或回滚到 svn 仓库。它的“版本控制”相关功能仅限于本地历史记录（比如编辑器的 ctrl+z）、sql 执行日志或备份快照，和 svn 这类集中式版本控制系统无关。
数据库建模文件需手动纳入 SVN 管理
Navicat 导出的模型文件（如 .nmmp、.nmm 或导出的 .sql 脚本）是普通文件，可被 SVN 跟踪，但必须靠外部工具操作：
- 用 TortoiseSVN 或命令行
svn add将模型文件加入仓库 - 每次修改模型后，手动执行
svn commit提交变更 - 回滚建模改动时，不能在 Navicat 里点“回滚”，而要：
— 用svn log查目标版本号
— 执行svn update -r [版本号]恢复本地模型文件
— 再用 Navicat 重新打开该.nmmp文件 - 注意：
.nmmp是二进制格式，SVN 无法做文本合并；多人协作时极易冲突，建议优先导出为可读的.sql或DDL脚本再提交
“回滚数据库”和“回滚建模”是两回事
很多人混淆这两个动作：
-
Navicat → 右键数据库 → 回滚：依赖数据库自身的日志（如 MySQL binlog、SQL Server transaction log），作用于**运行中的数据**，与 SVN 无关 -
SVN → revert / merge -c：作用于**本地磁盘上的模型文件或 SQL 脚本**，不触碰数据库实例 - 想还原某次建模导致的错误 DDL？必须先确认那个 DDL 是否已执行到库——如果执行了，光 SVN 回退文件没用，还得配合数据库级回滚（如用
ROLLBACK TO SAVEPOINT或时间点恢复）
真正可行的协同流程是分层的
把建模、脚本、执行、验证拆开管理，比强行“集成”更可靠：
- 建模阶段：Navicat 设计 → 导出为
schema_v20260604.sql→svn add & commit - 部署阶段：用
mysql -u... 执行，而非直接在 Navicat 里“同步模型到库” - 回滚需求出现时：
— 先svn update -r 123拿回旧版 SQL
— 再人工检查是否需要DROP/ALTER补丁，或走数据库备份恢复
— 不依赖 Navicat 图形界面里的任意“回滚”按钮
关键点在于：Navicat 的图形化操作（尤其是右键菜单里的“回滚”）从不操作 SVN，也不生成可版本化的中间产物。任何指望它自动联动 SVN 的尝试，最后都会卡在文件权限、二进制差异或事务边界上。
