Import data to the version Library

Import

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 "version library layout" Section 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 ready comings:

• 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 the "Import appropriate location" section. but since you are here, this is how the basic import works...

Before importing your project to the version library, you should:

1. Delete all files not required for the build project (temporary files, files generated by the compiler, such as *. OBJ, binary files generated ,...)

2. Organize files in directories and subdirectories. Although you can rename or delete files in the future, we recommend that you make the project structure well organized before import!

Now go to resource manager, select the top-level directory of your project, and right-click to open the context menu. Select tortoisesvn> Import.... A dialog box is displayed:

Figure 5.6. Import dialog box

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 realize that the local folder you are importing does not itself appear in the repository, only its content. for example if you have a structure:

C:\Projects\Widget\sourceC:\Projects\Widget\docC:\Projects\Widget\images

And you importC:\Projects\WidgetIntohttp://mydomain.com/svn/trunkThen you may be surprised to find that your subdirectories go straighttrunkRather than being inWidgetSubdirectory. 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.

This input will be used for submitting logs.

By default, files and folders that match the global ignore ModeNoImported. You can use the include ignore File validation column to disable this behavior. For more information about the global ignore mode, see the General Settings section.

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 isNotUnder version control! To get a version-controlledWorking copyYou need to do a checkout of the version you just imported. Or Read on to find out how to import a folder in place.

Import the appropriate location

If you already have a version library and want to add a new directory structure to it, follow these steps:

1. Use the version library browser to directly create a project folder in the version library.

2. Check out the new directory in the folder you want to import. You will get a warning that the local directory is empty. Now you have a version-controlled top-level directory that contains content not under version control.

3. In this version-controlled folder, use tortoisesvn → add some or all content. You can add or delete files and set them in folders.svn:ignoreAttribute, or other modifications you need.

4. Submit the top-level directory. You have a new version tree and a local working copy created from your existing Directory.

Private files

Sometimes you need to control a version that contains user-specific data. It means that you have a file, and every developer/user needs to modify it to satisfy his/her local configuration. However, Version Control is difficult because each user may submit his/her modifications.

In this case, we recommend that you useTemplateFile. Create a file that contains the data required by all developers and add it to the version library for developers to check out. Then, each developerCreate a copy, Rename this file. Therefore, modifying this file is no longer a problem.

For example, you can look at tortoisesvn's build script. It callsTortoiseVars.batFile, which is not in the version library. OnlyTortoiseVars.tmplIn the version library.TortoiseVars.tmplIs a template file. Each developer needs to create a copy and change its nameTortoiseVars.bat. In this file, we added comments, so users know the lines they need to edit to adapt to their local configurations so that they can work.

So in order not to interfere with users, we alsoTortoiseVars.batAdded to its parent directory's ignore list, that is, we set the Subversion attribute.svn:ignoreContains the file name. In this way, each submission will not appear as a file without version control.

Referenced Project

Sometimes it is useful to build a working directory that requires different detection. For example, you need different subdirectories from different locations of the version library ., Or it may come from different version libraries. If you want each user to have the same directory structure, you can definesvn:externalsAttribute.

Let's say you check out a working copy/project1ToD:\dev\project1. Select the folderD:\dev\project1, Right click and choose windows menu → properties from the context menu. the Properties dialog comes up. then go to the Subversion tab. there, you can set properties. click Add .... selectsvn:externalsProperty from the ComboBox and write in the edit box the repository URL in the formatname urlOr if you want to specify a special revision,name -rREV urlYou 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%20. Note that it is not possible to use folder names with spaces in them. Suppose that you have set these properties onD:\dev\project1:

sounds   http://sounds.red-bean.com/reposquick_graphs  http://graphics.red-bean.com/repos/fast%20graphicsskins/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-FolderD:\dev\project1\soundsAnd Checkout the sounds project, another sub-FolderD:\dev\project1\quick graphsContaining the graphics project, and finally a nested sub-FolderD:\dev\project1\skins\toolkitContaining revision 21 of the skin-maker project.

Prompt

You shoshould stronugly 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 wayTheyLooked back when your repository was at that previous revision. For software projects, this cocould be the difference between a successful and a failed build of an older snapshot of your complex code base.

If an external project is located in the same version library and you submit your modifications to the main project, your modifications to the external project will also be included in the submission list.

If the external project is located in a different version library, your modifications to the external project will be reported when you submit your modifications to the main project, however, you must submit modifications to these external projects separately.

If you use absolute URLs insvn:externalsDefinitions 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 done: onehttp://example.com/svn/repos-1And anotherhttp://example.com/svn/repos-2. We have a checkouthttp://example.com/svn/repos-1/project/trunkIntoC:\WorkingAndsvn:externalsProperty is set on trunk.

Relative to parent directory

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

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

This will extracthttp://example.com/svn/repos-1/widgets/fooIntoC:\Working\common\foo-widget.

Note that the URL is relative to the URL of the directory withsvn:externalsProperty, 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 extracthttp://example.com/svn/repos-1/widgets/fooIntoC:\Working\common\foo-widget.

You can easily refer to other repositories with the sameSVNParentPath(A common directory holding several repositories). For example:

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

This will extracthttp://example.com/svn/repos-2/hammers/clawIntoC:\Working\common\claw-hammer.

Relative to Solution

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 usehttp://While external clients usesvn+ssh://. For example:

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

This will extracthttp://example.com/svn/repos-1/widgets/fooOrsvn+ssh://example.com/svn/repos-1/widgets/fooDepending on which method was used to checkoutC:\Working.

Relative to the server host name

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 extracthttp://example.com/svn/repos-1/widgets/fooIntoC:\Working\common\foo-widget. But if you checkout your working copy from another serversvn+ssh://another.mirror.net/svn/repos-1/project1/trunkThen the external reference will extractsvn+ssh://another.mirror.net/svn/repos-1/widgets/foo.

If you want tortoisesvn to process more information about attributes, read the "Project Settings" section.

If you need to know the different methods for accessing public subprojects, read the section "include a common subproject.