命令 svn import 可以快速地向仓库中添加新文件 或目录. svn import 不要求工作副本, 新增的文件会 马上提交到仓库中. 使用该命令的典型情况是用户想要把一个已存在的目录 添加到 Subversion 仓库中, 例如:

$ svn import /path/to/mytree \
             http://svn.example.com/svn/repo/some/project \
             -m "Initial import"
Adding         mytree/foo.c
Adding         mytree/bar.c
Adding         mytree/subdir
Adding         mytree/subdir/quux.h

Committed revision 1.
$

上面的例子把本地目录 mytree 中的内容添加到 仓库的 some/project 目录中. 注意, 用户在导入 前无需创建新目录 — svn import 会自动完成这 些工作. 提交后, 用户就可以在仓库中看到新增的文件和目录:

$ svn list http://svn.example.com/svn/repo/some/project
bar.c
foo.c
subdir/
$

注意, 导入完成后, 本地的原始目录并没有被转换成工作副本, 为了能够以 版本控制的方式对文件进行管理, 用户仍然需要创建一份最新的工作副本.

为了方便用户管理数据, Subversion 提供了很大的灵活性. Subversion 只是简单地对目录和文件进行版本控制, 不会给它们附上特殊的意义, 用户 完全可以按照自己的喜好来决定数据的布局. 不过, 这种灵活性有时也会带 来一些麻烦, 如果用户同时在 2 个或多个布局完全不同的仓库中浏览, 而这 些仓库的布局又没有规律, 用户往往会感到迷失, 不知身在何处.

为了避免这种问题, 我们推荐读者遵循传统的仓库布局 (这种布局 出现在很久以前, 在 Subversion 项目早期阶段就已经开始使用), 传统布局的 特点是, 仓库中的目录名可以向用户传达出与它们所存放的数据相关的信息. 大多数项目都有一条公认的开发 “主线”, 或者叫作 主干 (trunk); 还有一 些 分支 (branches), 分 支是某一条开发线的分叉; 还有一些 标签 (tags), 标签是某一条开发线的稳定版快照. 我们首先建议 每一个项目在仓库中都一个公认的 项目根目录 (project root), 目录中只存放和该项目相关的 数据. 然后, 我们建议每一个项目根目录下都有一个表示开发主线的 trunk 子目录, 存放所有分支的 branches 子目录, 存放所有标签的 tags 子目录. 如果仓库只存放单个项目, 那么仓库的根目录也可以作为项目根目录.

这里有一些例子:

$ svn list file:///var/svn/single-project-repo
trunk/
branches/
tags/
$ svn list file:///var/svn/multi-project-repo
project-A/
project-B/
$ svn list file:///var/svn/multi-project-repo/project-A
trunk/
branches/
tags/
$

关于标签和分支的更多内容, 我们将在 第 4 章 分支与合并 介绍. 如果用户要为多个项目创建仓库, 其中的细节与建议请参考 “仓库布局”一节. 关于项目根目录的更多 内容, 我们将在 “规划仓库的组织方式”一节 介绍.

Subversion 尽量不去限制用户想要管理的数据类型, 文件的内容及其 属性被看成二进制数据进行存放和传输, “文件内容类型”一节 将会介绍如何向 Subversion 提示某个文件不需要 “文本” 操作. 然而, 在有些 地方, Subversion 会限制其中所存放的数据类型.

某些数据由 Subversion 内部进行处理 — 例如属性名, 文件路径, 日志消息 — 这些数据使用 UTF-8 编码, 不过这并不意味着和 Subversion 交互时一定要使用 UTF-8 编码, 一般情况下, Subversion 客户端会自动对 编码进行转换, 不需要用户参与.

在 WebDAV 交换数据过程和版本比较老的 Subversion 管理文件中, 文件路径是 XML 的属性值, 属性名是 XML 的标签名, 此时文件路径只能包含合法的 XML (1.0) 字符, 属性也只能使用 ASCII 字符. Subversion 禁止在文件路径 中出现 TAB, CR 和 LF 这些字符, 这是为了避免在差异比较时, 或者在命令 svn log 和 svn status 和输出中 文件路径被错误地断开.

听起来有许多规则需要记住, 但是在实际使用时这些限制极少会对用户产 生影响. 只要用户的本地化设置和 UTF-8 兼容, 而且不在文件路径中使用 控制字符, 在和 Subversion 通信时就不会产生任何问题. 客户端命令行工具 也能提供帮助 — 为了方便内部使用, 用户在输入 URL 时, 命令行工具 自动地对非法路径字符进行转义, 从而创建出方便内部使用的合法路径.

	警告
	在选择有效的路径名时, Subversion 不是唯一的限制因素, 使用多个 操作系统的开发团队还需要考虑不同操作系统对路径名的限制. 例如, Windows 不允许文件名包含冒号, 但是使用 Linux 系统的用户可以轻易地 在仓库中添加这样的文件, 这些文件将不能被 Windows 用户检出. 有些 操作系统区分文件名的大小写, 而有些不区分. 所以和 Subversion 相比, 用户更应该注意不同的操作系统和文件系统所产生的限制.