If you are importing into an existing repository which already contains some projects, then the repository structure will already have been decided. If are importing data into a new repository then it is worth taking the time to think about how it will be organised. Read “版本库布局”一节 for further advice.

This section describes the Subversion import command, which was designed for importing a directory hierarchy into the repository in one shot. Although it does the job, it has several shortcomings:

  • There is no way to select files and folders to include, aside from using the global ignore settings.

  • The folder imported does not become a working copy. You have to do a checkout to copy the files back from the server.

  • It is easy to import to the wrong folder level in the repository.

For these reasons we recommend that you do not use the import command at all but rather follow the two-step method described in “导入适当的位置”一节. But since you are here, this is how the basic import works ...


  1. 删除所有构建工程不需要的文件(临时文件,编译器产生的文件,例如 *.obj,生成的二进制文件,...)

  2. 组织目录和子目录内的文件。尽管以后可以改名/删除文件,我们还是建议你在导入之前使你的项目结构组织良好!

现在进入资源管理器,选择你的项目的顶层目录,右击打开上下文菜单。选择命令TortoiseSVN导入 ...,它会弹出一个对话框:

图 5.6. 导入对话框


In this dialog you have to enter the URL of the repository location where you want to import your project. It is very important to realise that the local folder you are importing does not itself appear in the repository, only its content. For example if you have a structure:


and you import C:\Projects\Widget into http://mydomain.com/svn/trunk then you may be surprised to find that your subdirectories go straight into trunk rather than being in a Widget subdirectory. You need to specify the subdirectory as part of the URL, http://mydomain.com/svn/trunk/Widget-X. Note that the import command will automatically create subdirectories within the repository if they do not exist.



As soon as you press OK TortoiseSVN imports the complete directory tree including all files into the repository. The project is now stored in the repository under version control. Please note that the folder you imported is NOT under version control! To get a version-controlled working copy you need to do a Checkout of the version you just imported. Or read on to find out how to import a folder in place.



  1. 使用版本库浏览器直接在版本库中创建项目文件夹。

  2. 在你要导入的文件夹检出新目录。你会得到一个本地目录为空的警告。现在你有一个版本控制的顶级目录,含有未版本控制的内容。

  3. 在此受版本控制的文件夹上使用TortoiseSVN增加...增加部分或全部内容。你可以增加或删除文件,在文件夹上设置svn:ignore属性,或者你需要的其它修改。

  4. 提交顶级目录,你有一个新的版本树,一份从你已有目录创建的本地工作副本。




作为例子,你可以看看TortoiseSVN的构建脚本。它调用一个TortoiseVars.bat文件,它并不在版本库中。 只有TortoiseVars.tmpl在版本库中。TortoiseVars.tmpl是一个模版文件,每个开发者都需要创建一个副本,改名为TortoiseVars.bat。在这个文件中,我们增加了注释,所以用户知道他们需要编辑那些行,以便适应他们的本地配置,使其能工作。




Let's say you check out a working copy of /project1 to D:\dev\project1. Select the folder D:\dev\project1, right click and choose Windows MenuProperties from the context menu. The Properties Dialog comes up. Then go to the Subversion tab. There, you can set properties. Click Add.... Select the svn:externals property from the combobox and write in the edit box the repository URL in the format name url or if you want to specify a particular revision, name -rREV url You can add multiple external projects, 1 per line. Note that URLs must be properly escaped or they will not work. For example you must replace each space with %20. Note that it is not possible to use folder names with spaces in them. Suppose that you have set these properties on D:\dev\project1:

sounds   http://sounds.red-bean.com/repos
quick_graphs  http://graphics.red-bean.com/repos/fast%20graphics
skins/toolkit -r21 http://svn.red-bean.com/repos/skin-maker

Now click Set and commit your changes. When you (or any other user) update your working copy, Subversion will create a sub-folder D:\dev\project1\sounds and checkout the sounds project, another sub-folder D:\dev\project1\quick graphs containing the graphics project, and finally a nested sub-folder D:\dev\project1\skins\toolkit containing revision 21 of the skin-maker project.


You should strongly consider using explicit revision numbers in all of your externals definitions, as described above. Doing so means that you get to decide when to pull down a different snapshot of external information, and exactly which snapshot to pull. Besides the common sense aspect of not being surprised by changes to third-party repositories that you might not have any control over, using explicit revision numbers also means that as you backdate your working copy to a previous revision, your externals definitions will also revert to the way they looked in that previous revision, which in turn means that the external working copies will be updated to match they way they looked back when your repository was at that previous revision. For software projects, this could be the difference between a successful and a failed build of an older snapshot of your complex code base.



If you use absolute URLs in svn:externals definitions and you have to relocate your working copy (i.e., if the URL of your repository changes), then your externals won't change and might not work anymore.

To avoid such problems, Subversion clients version 1.5 and higher support relative external URLs. Four different methods of specifying a relative URL are supported. In the following examples, assume we have two repositories: one at http://example.com/svn/repos-1 and another at http://example.com/svn/repos-2. We have a checkout of http://example.com/svn/repos-1/project/trunk into C:\Working and the svn:externals property is set on trunk.


These URLs always begin with the string ../ for example:

../../widgets/foo  common/foo-widget

This will extract http://example.com/svn/repos-1/widgets/foo into C:\Working\common\foo-widget.

Note that the URL is relative to the URL of the directory with the svn:externals property, not to the directory where the external is written to disk.

Relative to repository root

These URLs always begin with the string ^/ for example:

^/widgets/foo  common/foo-widget

This will extract http://example.com/svn/repos-1/widgets/foo into C:\Working\common\foo-widget.

You can easily refer to other repositories with the same SVNParentPath (a common directory holding several repositories). For example:

^/../repos-2/hammers/claw  common/claw-hammer

This will extract http://example.com/svn/repos-2/hammers/claw into C:\Working\common\claw-hammer.


URLs beginning with the string // copy only the scheme part of the URL. This is useful when the same hostname must the accessed with different schemes depending upon network location; e.g. clients in the intranet use http:// while external clients use svn+ssh://. For example:

//example.com/svn/repos-1/widgets/foo  common/foo-widget

This will extract http://example.com/svn/repos-1/widgets/foo or svn+ssh://example.com/svn/repos-1/widgets/foo depending on which method was used to checkout C:\Working.


URLs beginning with the string / copy the scheme and the hostname part of the URL, for example:

/svn/repos-1/widgets/foo  common/foo-widget

This will extract http://example.com/svn/repos-1/widgets/foo into C:\Working\common\foo-widget. But if you checkout your working copy from another server at svn+ssh://another.mirror.net/svn/repos-1/project1/trunk then the external reference will extract svn+ssh://another.mirror.net/svn/repos-1/widgets/foo.