The ignore list is constructed from two sources:

1. the client specific global-ignores list;
2. any svn:ignore property associated with the directory into which the file is being added.

The global-ignores configuration parameter is set in the client’s config file and applies to all additions executed from that client (excluding those that specify the command line option –no-ignore). To this global-ignores list is added, on a directory by directory basis, any patterns associated with svn:ignore properties associated with directories.

The ignore list becomes a little more complicated when combined with wildcards in file names provided to the add commands. Rather than write a long post on the subject I have provided an extract from my Subversion training course (divided into two parts here because of YouTube length restrictions, it’s all one video in the course Oh, and WordPress, who host this blog, do not support embedded playlists. If you prefer to watch this as a playlist, go here).

If you watch these videos here I suggest you expand then to full screen otherwise they’re too small to read (again, this is a limitation of wordpress.com hosting).

Part 1

Part 2

• trunk, where the main development is often (though not necessarily) done;
• branches, where (unsurprisingly) we maintain branches that may be used for any number of reasons to isolate some sequence of changes from the trunk;
• tags, where we maintain tagged sets of files and directories.

It is this last area tags that this post considers in more detail.

Creating a basic tag

Creating a simple tag is incredibly fast and simple. Simply copy the thing to be tagged into the tags directory.

svn copy http://subversion/myrepo/trunk http://subversion/myrepo/tags/release_1.0

This command creates a copy of the current revision of the trunk in tags/release_1.0. Creating this copy is very quick and requires almost no resources in the repository’s virtual file system*.

Selectively tagging

So, creating a straightforward tag is simple but what about more complex tags? What if we want to tag only selected files and directories within our trunk?

There are many ways that this can be achieved. We will examine just one of these methods here*. In this example we will create a new working copy for the tag and manually populate it with items from the repository. This method is suitable when using Subversion 1.5+ and provides complete control over what is tagged and how it is recorded in the tag.

First we need to create a working copy to hold the tag. Again, there are several methods of doing this. The method shown here allows the entire tag to be created as a single transaction (more closely emulating the creation of simple tags).

svn co --depth=empty http://subversion/myrepo/tags
svn mkdir tags/mynewtag

These first two commands checkout the tags directory (but none of the existing tags are checkout because we have specified –depth=empty. The mkdir command then creates an empty directory mynewtag in the tags working copy.

We have not yet created a tag in the repository’s virtual file system, but we have prepared a working copy which, when committed will do just that.

Having prepared our working copy we now copy items into it. In this example we are copying items from the repository into the working copy.

cd tags/mynewtag
svn copy http://subversion/myrepo/trunk/file1.txt .
svn copy --parents http://subversion/myrepo/trunk/dir1/file2.txt dir1/file2.txt

Notice that when copying files into nested directories I have chosen to preserve the directory structure. Using the –parents option ensures that all the necessary intermediate directories are created and scheduled for addition as part of the copy operation.

We do not have to preserve the directory structure.

svn copy http://subversion/myrepo/trunk/dir1/file3.txt file3.txt

This command will create a tagged version of the dir1/file3.txt in tags/mynewtag/file3.txt. Similarly we can rename files, or assign them into other directories.

We can also tag complete sub-directories just as simply.

svn copy http://subversion/myrepo/trunk/dir2 dir2

This tags the whole trunk/dir2 as tags/mynewtag/dir2.

Using the –revision option we can control precisely which revisions are tagged (the default being HEAD).

svn copy --revision 4 http://subversion/myrepo/trunk/dir3 dir3

This command tags the revision 4 of trunk/dir3 as mynewtag/dir3.

Once we are happy that our mynewtag working copy contains all of the items we want in the tag, we commit the entire working copy to create the tag in the repository.

cd ..
svn commit -m "Create mynewtag" .

* If you found this post useful and are keen to learn more about Subversion, you may be interesting in my Subversion Client training course.
Or, for more answers to Subversion questions, try my Subversion FAQ.

The problem is that, when using svnserve and the internal password-db, usernames and passwords are held in a plain text file, usually within the conf directory of the repository to which they apply. This file cannot be made read/writeable to all users because this would allow all users to both see and change one other’s passwords (which would be very silly).

The usual solution to this is for the administrator to issue passwords to users and whenever a user wishes to change their password they ask the administrator to do it for them.

Here is a method for allowing users to change their own passwords. In summary, this is a hook script that intercepts requests to delete a special file. When an attempt is made to delete this special file the script assumes that the log message is the new password to be set for the user who requests the deletion. It then changes the entry in the local Subversion password database and rejects the request to delete the file.

Full details are available on the Principia Subversion FAQ.

You’ll want to watch this full screen and in HD to get the best view.

This video is part of the upcoming Subversion Guru training course.

Before you start removing paths from your repository consider this: Subversion was not designed to have paths removed. That is why you cannot remove paths using the standard client interface, in fact you need to be an administrator and have direct access to the repository’s physical file system. Removing paths from a repository is a last resort. (There is a suggestion for an svn obliterate feature to provide path removal through the standard client, for which a functional specification has been placed in the Subversion development notes, but until this is implemented the following is the only mechanism available for permanently removing paths from a repository.)

Why might you want to permanently remove a path from your repository? Legitimate reasons include:

• Archive old material from a very large repository to save space.
• Remove sensitive information from a repository (perhaps added accidentally)

Strictly speaking we do not actually remove paths from a repository, we build a completely new repository. To do this we use three commands; svnadmin dump, svndumpfilter, svnadmin load.

svnadmin dump

The svnadmin dump command creates a stream of data that  describes all of the data in the repository’s virtual file system.

svnadmin dump /path/to/repository

This command will produce a stream of data describing the content of the repository at path /path/to/repository. This stream of data is sent to STDOUT, usually the screen by default.

The output from svnadmin dump can be redirected into a file, for example.

svnadmin dump /svn/oldrepos > dump.file

This command will create a dump file called dump.file containing all of the output from the svnadmin dump command.

svnadmin load

The svnadmin load command performs the opposite function to svnadmin dump. It takes a stream of data describing the content of a repository and loads in into a repository database. The stream is read from STDIN, usually the keyboard by default.

svnadmin load /path/to/repository

This command will read a stream of data from STDIN and place it into the repository at /path/to/repository.

The repository at path /path/to/repository must exist before you run the svnadmin load command.

Similarly to the svnadmin dump command, input can be redirected.

svnadmin load /svn/newrepos < dump.file

This command will read in the file dump.file to STDIN for the svnadmin load command to process. In this way you can process the dump file and then load it into another repository.

If you wanted to copy a repostory you could use dump and load as follows.

svnadmin create /svn/newrepos
svnadmin dump /svn/oldrepos | svnadmin load /svn/newrepos

Here the output from the svnadmin dump command is being piped directly into the svnadmin load command with no intermediate dump file. We will use this technique a little later to create one command line to build a new repository with paths filtered out from the original.

svndumpfilter

svndumpfilter reads input from STDIN and produced output to STDOUT. It will also include or exclude specified paths as it encounters them.

This allows us to svnadmin dump a repository, filter the data with svndumpfilter and then insert the filtered data into another repository with svnadmin load

The svndumpfilter has two sub-commands, include and exclude. As their names suggest these specify paths we want to include in, or exclude from, the data processed through svndumpfilter.

svndumpfilter exclude trunk

This command will read data from STDIN, remove any references to paths beginning trunk, and write the resulting data to STDOUT.

If we have a dump file called dump.file from which we want to remove all paths beginning trunk and create a new dump file called newdump.file we use the following command.

svndumpfilter exclude trunk < dump.file > newdump.file

We can bypass the need to use these intermediate files and chain all three commands together.

Suppose I have a repository at /svn/repos and I want to remove all paths starting trunk/mistake. We create a new, empty repostory to receive the processed data, then use svnadmin dump, svndumpfilter and svnadmin load to do all the heavy lifting.

svnadmin create /svn/newrepos
svnadmin dump /svn/repos | \
 svndumpfilter exclude trunk/mistake | \
 svnadmin load /svn/newrepos

[Note: The '\' indicates a line continuation. The last three lines in the previous example are all one command line]

Once this is complete, we have two repositories; /svn/repos and /svn/newrepos. You now need to replace /svn/repos with /svn/newrepos (the subject perhaps of another post).