I wasn’t seeing enough benefit to FAlbum, so I removed it. Too slow and confusing for my tastes.

Also, I got sick of the monthly updates to WordPress, so I finally switched over to using the subversion method. Now an upgrade is as simple as an svn update and click the Upgrade button.

A client of mine recently came to me with issues updating subversion from his Windows box. After some investigation, I figured out that the problem was that subversion had two copies of a file, “logo.png” and “logo.PNG”, the difference being one of the extensions was capitalized. This didn’t appear to be that uncommon, I know of at least one Windows app that saves all files as capital extensions by default (MSPaint). Committing these files is perfectly legal with subversion, and since it is hosted on a FreeBSD box, those files are perfectly distinct. But Windows is a case insensitive OS, so it viewed those files as one and the same. When updating, the SVN client would grab one, then attempt to grab the second and fail with an error message similar to “Object of same name already exists.”

Using tortoise SVN, there was no easy way to fix this issue. You can’t update to a working copy because of the issue, and so you couldn’t delete and recommit. On a non windows box I had to delete one or the other, then recommit. Tortoisesvn.net had a solution that didn’t really work for me, because each time I would attempt it, it would error out and I’d have to cleanup, effectively restarting the operation. Once the problem is resolved, they suggest a pre-commit hook script which would detect for a case insensitive filename clash. Were I too concerned that my client hadn’t learned his lesson, I would implement that. However, more careful usage can avoid this issue.

So I setup a Subversion repository successfully. Well, turns out it wasn’t complete.

My client would like to access and change files via Subversion instead of what they were currently using, FTP. Moreover, they would like the files to exist in their webroot of their domain. Their project is a web project, after all.

After some research and discussion with peers, I found out how to do this. First, I had to add their directory as accessible via subversion. I used Subversion’s FAQ about in-place import to do what I needed. My exact commands were:
# svn mkdir file:///home/svn/rep/{repname}/domain.com -m "Initial create"
# cd /home/{user}
# svn checkout file:///home/svn/rep/{repname}/domain.com
# svn add *
# svn commit -m "Initial version of files"

That seemed to work great, the repository was setup! My client had access to read and write files to their repository, which is their webroot. However, the webroot doesn’t auto-update, so any changes won’t take effect unless it’s manually updated.

Reading further in the Subversion FAQ, I found a way to auto update the files on the website.
I created a “Tiny C” app with the following code
#include <stddef.h>
#include <stdlib.h>
#include <unistd.h>
int main(void)
{
execl("/usr/local/bin/svn", "svn", "update", "/home/{user}/domain.com",
(const char *) NULL);
return(EXIT_FAILURE);
}

Then compiled it

cc -o updaterepo postcommit.c

Then made updaterepo executable and gave it chmod +s, as suggested by the FAQ. Of course I made it owned by {user} as well. Then I created /home/svn/rep/{repname}/hooks/post-commit with the following content

#!/bin/sh
/home/{user}/updaterepo

I tested a commit, and it worked!

I haven’t yet needed to use the subversion repository that I setup awhile ago. A client of mine required it, so I spent the time and set them up a repository, and it seems to be working alright. Here’s what I did.

svnadmin create /home/svn/rep/{repname}

That’s it. Then I edited the conf/svnserve.conf and conf/passwd files for their users. This is the e-mail I sent them:

I setup your subversion repository. Let me know if you have any problems accessing. Here’s a guide to configuring tortoise svn on Windows, you can probably extrapolate it to a Mac SVN client.

First: install tortoise svn
http://tortoisesvn.net/downloads
Reboot as necessary
Create a directory on your computer for the repository, lets say
C:\repos\
Go to windows explorer and right click on the C:\repos\ folder.
Click SVN Checkout
IMPORTANT: For the URL of the repository put
svn://user:pass@{url}/repos
Click OK, it should Completed, click OK.
That should be it, past that it’s all up to you guys.

To add files, put a file in that directory then right click on it and go
to TortoiseSVN=>Add, then right click on it and go to SVN Commit.

Before you start working, right click on that folder and go to SVN Update.

That should be it.

Let me know if there are any problems.

Ray

P.S. Oh, and as a word of caution, I’ve heard there are some major problems with copying/pasting files from withing a repository, so just don’t do it without expecting to mess up the repository. You can google why or maybe a workaround.

When I was working on Havoc Command, my team ran into a copy/paste problem… it was not fun.

I had some trouble with this some months ago, so I thought I would create a guide to do it for my own future reference. The OS I used for this guide was FreeBSD 5.4, but it stands to reason that it would work on others.

First, install subversion from the ports

[root@sam ~]# cd /usr/ports/devel/subversion
[root@sam /usr/ports/devel/subversion]# make install clean

Next, add a user for the subversion server to run under. I made mine “svn” at “/home/svn”. And I made a directory for the repository “/home/svn/rep”.

Next, setup your /etc/rc.conf so that the svn server will start on boot, or start at all. Append this to /etc/rc.conf

#svn server
svnserve_enable="YES"
#svnserve_flags="-d --listen-port=3690 --listen-host=0.0.0.0"
svnserve_flags="-d -r /home/svn/rep --listen-host=0.0.0.0"
svnserve_data="/home/svn/rep"
svnserve_user="svn"
svnserve_group="svn"

Start your svn server

[root@sam ~]# /usr/local/etc/rc.d/svnserve.sh start

Create the repository with svn

[root@sam ~]# svnadmin create /home/svn/rep

Explicitly set the password file, edit {repository}/conf/svnserve.conf and uncomment the line

password-db = passwd

and do whatever other edits to fine tune your repository.

Edit the password file to your liking, setting up a user with write access. The password file is {repository}/conf/passwd

And wha-la, presto