Flylib.com

Books Software

 
 
 

Section 4.2. Getting Files into the Repository


4.2. Getting Files into the Repository

Now that you have created the empty repository, it's time to get the project files into it. To do this, you need to put the files into a basic directory structure for the repository, and then import the entire structure. It would be possible to make that directory structure as simple as a single directory named hello_world , with hello.c and Makefile inside. In practice, though, this isn't a very good directory structure to use.

If you recall from the previous chapter, Subversion does not have any built-in support for branches or tags, but instead just uses copies. This proves to be a flexible way to handle branches and tags, but if they're just copies, there is no set means for identifying what files are branches and what files are on the main source trunk. The recommended way to get around this missing information is to create three directories in your repository, one named branches , another named tags , and a third named trunk . Then, by convention, you can put all branched versions of the project into the branches directory and all tags into the tags directory. The trunk directory will be used to store the main development line of the project.

With large, complex repositories, there are a number of different ways you can set up the directories for the trunk, branches, and tags, which can accommodate multiple projects in one repository, or facilitate different development processes. Because our test project is simple though, we'll keep the repository simple and place everything at the top level of the repository. So, to get everything set up, you first need to create an overall directory for the repository, called repos . Then, set up trunk , branches , and tags directories under that, and move the original source files for the project into the trunk directory.

$ mkdir repos
$ mkdir repos/trunk
$ mkdir repos/branches
$ mkdir repos/tags
$ ls repos
branches tags trunk
$ mv hello.c repos/trunk/
$ mv Makefile repos/trunk/
$ ls repos/trunk/
Makefile hello.c

After the directories are created and filled, the only thing left to do is import the directory into our repository. This is done using the import command in the svn program.

$ svn import --message "Initial import" repos file:///home/bill/repositories/my_repository
Adding     repos/trunk
Adding     repos/trunk/hello.c
Adding     repos/branches
Adding     repos/tags

Committed revision 1.

The --message "Initial import" option in the preceding example is used to tell Subversion what to use as a log message for the import. If you omit the --message option when you are importing or committing files to the repository, Subversion will automatically open an editor for you, [1] which will allow you to type a log message as long and complex as you need it to be.

[1] See Section 7.2, "Editing the Configuration Files."

Now that the repository structure has been imported, you can delete the original files. Everything should now be stored in the database, and ready for you to check out a working directory and begin hacking.


4.3. Creating a Working Copy

The working copy is where you make all of your changes to the files in the repository. You check out the working copy directory by running the svn checkout command, and it contacts the repository to retrieve a copy of the most recent revision of all the data in your repository. A local directory tree that matches the tree inside the repository will be created, and the downloaded working directory files will be placed in there.

$ svn checkout file:///home/bill/my_repository/trunk my_repos_trunk
A my_repos_trunk/hello.c
A my_repos_trunk/Makefile
Checked out revision 1.

As you can see, Subversion has checked out the trunk directory from your repository, creating a local working copy directory with the name my_repos_trunk , along with the files hello.c and Makefile that were stored in trunk . You'll notice, however, that the branches and tags directories were not checked out. Subversion will let you check out the entire repository at the top level, but doing so is generally not good practice. If you do, you may end up with multiple local copies of the source tree, because branches and tags are made by copying files. Instead, if you only check out the main trunk, you will ensure that you only have one version of the files at a time in your working copy. If you need to access specific branches or tags, you can either check them out on an individual basis, into their own working copies, or switch files in your trunk working copy to point to other locations in the repository (e.g. branches or tags), which I'll show you how to do in a later section.

Now, if you look closely at your new working copy, you can see that Subversion also has placed one additional directory in the directory that you checked out.

$ ls my_repos_trunk
Makefile hello.c
$ ls -A my_repos_trunk
.svn Makefile hello.c

When you check out a repository, Subversion places a .svn directory in every directory of the repository. Inside these directories, Subversion places a wide variety of metadata about the working directory, including what repository the working directory comes from and what revisions of each file have been checked out. It also stores complete pristine versions of the last checked-out revision of each file in the working directory. This allows Subversion to provide you with diffs showing what changes you have made locally to a file, without needing to contact the server.