Tag Archives: subversion

Reverting File Changes With git

This is not obvious to those of us with lingering Subversion habits comprar viagra madrid. If you’ve edited a file and simply want to discard its changes (à la Subversion’s revert), use:

git checkout filename

If it so happens that your file name is the same as a branch, you’ll need to use:

git checkout -- filename

Use the Right Tool for the Job

You may be tempted to use git reset --hard, but that will reset all uncommitted changes. If you just want to undo the changes to a single file, that’s the wrong tool.


Ignoring Files in Subversion from the Command Line

Subversion uses a directory’s svn:ignore tag to control the files that it ignores. The list is separated by carriage returns, which is a pain to do from the command line. Roman Mackocak has a nice reminder that subversion can be told to let you use an editor to edit the svn:ignore tag.

In summary,

  • Ensure that the EDITOR environment variable is set appropriately. (e.g. set EDITOR=vim)
  • Tell subversion you want to edit the svn:ignore tag.
$ svn propedit svn:ignore .
  • Edit the list, one entry per line.
  • Commit the changes when ready.

Setting Up a Subversion Server

The last time I set up a Subversion server was 2005. Here are notes I jotted down while installing a new server. There are a few gotchas along the way. Hopefully these notes catch all of them.


The goal is to set up a dedicated virtual machine to act as a Subversion repository. It resides in-house, off of the Internet.


Subversion can be run in several different ways. Some of those ways create the potential for file ownership to become a problem, causing subversion to fail in various inconvenient manifestations. The method I chose is to use xinetd to launch the Subversion dæmon running as a user dedicated for this purpose.

Where to store the Subversion repository is a matter of personal philosophy. Here I’ll put it in /opt/subversion.

This opens up the Subversion server port 3690. If you’re running on a machine directly connected to the Internet, you can consider not opening up that port to the world, and securely tunneling port 3690 using ssh.


  • Set up the server as you wish. I used CentOS 5.
  • Create a user for Subversion. Note that RedHat (and thus CentOS) creates a corresponding group by default.
$ sudo /usr/sbin/useradd -c "Subversion" svn
  • Install Subversion, and xinetd if not installed. Open up port 3690 in the firewall.
$ sudo yum install subversion xinetd
$ sudo /sbin/chkconfig --level 35 xinetd on
$ sudo /sbin/iptables -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 3690 -j ACCEPT
  • Create a Subversion configuration file for xinetd. Restart xinetd.
$ sudo vim /etc/xinetd.d/svn
$ sudo /etc/init.d/xinetd restart

The contents of the configuration file are along these lines:

service svn
    disable         = no
    socket_type     = stream
    wait            = no
    user            = svn
    server          = /usr/bin/svnserve
    server_args     = --inetd
    log_on_failure  += USERID
  • Prepare the directory for the subversion server.
$ sudo mkdir /opt/subversion
$ sudo chown svn.svn /opt/subversion
$ su svn -
$ svnadmin create --fs-type fsfs /opt/subversion/repository_name

Note that I’m not sure whether fsfs is default type for svnadmin nowadays, so I specified it explicitly. I don’t really see any reason to use Berkley DB and its associated risks for database corruption (a “wedged” database).

  • Edit the configuration files for your repository.
$ vim /opt/subversion/repository_name/conf/svnserve.conf
$ vim /opt/subversion/repository_name/conf/passwd

The passwd file is a plain text file with user names and passwords. The format should be obvious when you see the samples in the file. Note the security caveat here. This isn’t.

The server configuration file (svnserve.conf) values can be tailored to suit your needs. See the “Red Bean book” official documentation for details. (If you wish to support the project, you may consider buying the dead tree version from O’Reilley.) To allow only users with a password access to the repository, I used:

anon-access = none
auth-access = write
password-db = passwd
  • Test out the setup
$ su - fred
$ svn co svn://localhost/opt/subversion/repository_name

This should create a directory called repository_name. There should be nothing in it (except for the hidden .svn file).

  • It is common practice to create three subdirectories in a repository: branches, tags, and trunk.
$ cd repository_name
$ mkdir branches tags trunk
$ svn add branches tags trunk
$ svn commit -m "Create core directories for the repository"
  • If things have worked to this point, you should be able to use the repository from another computer using the URL svn://machine_name/opt/subversion/repository_name/trunk as you would normally.

Upgrading Subversion on OS X

Subversion Logo
I started receiving messages about my version of subversion being out of date. Jettro Coenradie wrote an article on how to upgrade the subversion client on your Mac.

It boils down to this:

  1. Download and run the latest Collabnet installer for subversion on the Mac.
  2. Ensure that your path includes /opt/subversion/bin before the old subversion path /usr/local/bin. For example, I have in my .bashrc file:
    # Check for Collabnet Subversion
    if [ -d /opt/subversion/bin ]; then
    export PATH=/opt/subversion/bin:$PATH
  3. If you have programs like SCPlugin that interact with Finder, log out and log back in so that all of your processes have the new path.