Sky’s Public Notes

Today I wanted to enable my local Apache HTTP Server on my Mac. The nice thing is, that OS X comes with Apache (didn’t have to install anything), but well, it didn’t really run out of the box, so here’s what I had to do.

First: I’ve Leopard (OS X 10.5) installed on my Mac but I don’t have a fresh install – I upgraded from Tiger (10.4), so maybe that’s the reason why Apache didn’t work right (but I don’t know, I’m just guessing…). My current OS X version is 10.5.5 and Apache is 2.2.9.

Well, first step is to enable the web server. Simply open “System Preferences”, go to “Sharing” and enable the checkbox close to “Web Sharing”. In theory that’s all you have to do; you should be able to access your local webserver at http://localhost and your user’s webpage at http://localhost/~username now.

But, my Apache didn’t start. The first problem was, that directory /private/var/log/apache2 was missing (I saw a log message about this error in the Console’s “All Messages” section), so I created it.

mbp:log gerhard$ pwd
/private/var/log
mbp:log gerhard$ sudo mkdir apache2
Password:

Afterwards http://localhost was accessible but my user’s webpage was not. When trying to access my user’s webpage I got an error 403 – “Forbidden” message. Apache’s error log (at /private/var/log/apache2/error_log) contained the following entry:

[Sun Nov 30 11:01:55 2008] [error] [client 192.168.1.211] client denied by server configuration: /Users/gerhard/Sites

So I took a closer look at Apache’s configuration and found out that there were two directories in /etc that could correlate with Apache. First, there was one configuration in /etc/httpd (this one is actually not in use) and then there’s another one in /etc/apache2 (that’s the important one). I don’t really know why there are two configurations, maybe that’s a relict from the upgrade procedure (Tiger to Leopard).

I found out that by default Apache doesn’t allow access to anything (configured in /etc/apache2/httpd.conf). Access to user folders is defined in the subdirectory /etc/apache2/users… and there was no configuration file for my user. Actually, the default config file existed in /etc/httpd/users, so all I had to do was to copy that file over to the right directory:

mbp:log gerhard$ pwd
/etc/apache2/users
mbp:users gerhard$ sudo cp /etc/httpd/users/gerhard.conf .
Password:

Then I restarted Apache (on the Terminal with sudo apachectl restart or by unchecking and checking the “Web Sharing” checkbox in System Preferences) and finally could access my local Apache on http://localhost/~gerhard.

Popcap’s game Zuma doesn’t offer an option to reset highscores. Well, from time to time it’s nice to restart from zero, especially if more than one person is playing on one computer and highscores grew so high that it became nearly impossible to beat them.

Resetting highscores is pretty easy. You only have to delete a file named “highscores.dat” and all highscores will be reset. User accounts and current saved games will not be removed, however, it’s a good idea to copy the highscores.dat file to another place or rename it, so – just in case – you can always put it back to its original place again (and have your highscores back).

Under Windows, this file is located in:

C:\Program Files\Popcap Games\Zuma Deluxe\userdata

If you use the Mac (OS X) version of the game, you’ll find the file in your user’s home directory:

~/Library/Application Support/Popcap/Zuma/userdata

Subversion’s most talked about new feature in version 1.5 is “merge tracking”. The idea of this feature is not new, but very useful. Subversion keeps track about which versions have been merged making merging faster and more comfortable. With Subversion 1.4 and earlier, Subversion didn’t know anything about what has been merged when by whom, and so on. Managing the whole merging theme was based on conventions and rules every project had to introduce.

E.g., in my projects I merged revision ranges from one branch into another and wrote a commit comment like this: “svn merge trunk 522:541”, meaning that I’ve committed a merge from trunk’s revision 522 to revision 541 into the current branch. Before performing such a merge (e.g., updating my development branch with the newest changes from trunk), I had to inspect the log history of the branch in order to find out up to which revision I already merged before. Then I had to take a look into the trunk’s log and find out up to which revision I wanted to merge now or what the current latest trunk revision was. After finding out these two revision numbers, I could do the merge, and commit changes with a comment like the one above.

Well, once one gets used to this procedure, it isn’t that time consuming… but, it is always error-prone because it depends on users obeying rules. If someone forgets adding the correct comment or writes wrong revision numbers into comments (typos…), it causes problems for the next merge…

After all, these are problems users shouldn’t have to care about. And that’s exactly where “merge tracking” helps.

First of all, merge tracking is one of those features of Subversion 1.5, which require a 1.5 client, 1.5 server and 1.5 repository. So, in order to benefit from this new feature, you have to upgrade your whole Subversion setup plus repository.

I’ll test merge tracking with a new local repository. Let’s do it step by step, so even if you don’t have experience with Subversion, you can follow these steps and try it out yourself. All you need is to have the Subversion client version 1.5 or higher installed.

Preparing a Test Environment

I go to a test directory “mytest/svn” and create a repository in directory “repo”. Then I checkout this new repository into a working copy called “trunk”.

mbp:svn gerhard$ svnadmin create repo
mbp:svn gerhard$ svn co file:///Users/gerhard/mytest/svn/repo trunk
Checked out revision 0.
mbp:svn gerhard$ cd trunk
mbp:trunk gerhard$ ls -al
total 0
drwxr-xr-x 3 gerhard gerhard 102 6 Nov 22:33 .
drwxr-x--- 11 gerhard gerhard 374 6 Nov 22:33 ..
drwxr-xr-x 8 gerhard gerhard 272 6 Nov 22:33 .svn

As there is really nothing in a new repository, let’s create basic directories, which should exist in every Subversion repository, add them to version control and commit them.

mbp:trunk gerhard$ mkdir trunk
mbp:trunk gerhard$ mkdir branches
mbp:trunk gerhard$ svn add trunk
A trunk
mbp:trunk gerhard$ svn add branches
A branches
mbp:trunk gerhard$ svn commit -m "initialization of repository"
Adding branches
Adding trunk
Committed revision 1.

Next, I switch the working copy to folder trunk, that’s where I actually wanted to be…

mbp:trunk gerhard$ svn switch file:///Users/gerhard/mytest/svn/repo/trunk
D trunk
D branches
Updated to revision 1.

Now I create two simple text files for testing. I name them “file1.txt” and “file2.txt” and add some lines of text to each of them.

mbp:trunk gerhard$ svn add file1.txt file2.txt
A file1.txt
A file2.txt
mbp:trunk gerhard$ svn commit -m "added file1.txt and file2.txt with some lines of text"
Adding file1.txt
Adding file2.txt
Transmitting file data ..
Committed revision 2.

So, that’s a good base to start doing some tests.

Creating a Branch and Merging Data

The diagram below shows what I’m planning to do now: create a branch (step 1), keep it up-to-date by merging changes from the trunk (steps 2 and 3) and finally merge the branch’s changes back into the trunk (step 4).

The first step is to create a branch. I create it under “branches” and name it “b1”.

mbp:trunk gerhard$ svn copy file:///Users/gerhard/mytest/svn/repo/trunk file:///Users/gerhard/mytest/svn/repo/branches/b1 -m "created branch b1 from trunk r2"
Committed revision 3.

Then I checkout the branch to a new local working copy in directory “b1”, add a line to file1.txt and commit changes.

mbp:trunk gerhard$ cd ..
mbp:svn gerhard$ svn co file:///Users/gerhard/mytest/svn/repo/branches/b1 b1
A b1/file2.txt
A b1/file1.txt
Checked out revision 3.
mbp:svn gerhard$ cd b1
mbp:b1 gerhard$ vi file1.txt
mbp:b1 gerhard$ svn commit -m "added a line to file1.txt"
Sending file1.txt
Transmitting file data .
Committed revision 4.

Now I go back to my trunk working copy and change file file1.txt, too. This time I add a line at the beginning of the file, so I will not have conflicts when merging later on.

mbp:trunk gerhard$ vi file1.txt
mbp:trunk gerhard$ svn commit -m "added a line to file1.txt"
Sending file1.txt
Transmitting file data .
Committed revision 5.

Afterwards, I merge changes from trunk to branch b1. At this point “merge tracking” can be used for the first time. Subversion knows that branch b1 has been created from trunk’s revision 2 and that there hasn’t been any merges performed so far. So, all I have to do here is to call “svn merge” and add the trunk’s path as parameter.

mbp:b1 gerhard$ svn merge file:///Users/gerhard/mytest/svn/repo/trunk
--- Merging r3 through r5 into '.':
U file1.txt
mbp:b1 gerhard$ svn status
M .
M file1.txt

Now that’s easy… works great. Note: Subversion changed the base directory “.”, too. It added metadata in a property called “svn:mergeinfo” for merge tracking. “svn diff” shows that this new property has been added to my base directory. It stores merge information in a readable form.

mbp:b1 gerhard$ svn diff
Property changes on: .
___________________________________________________________________
Added: svn:mergeinfo
Merged /trunk:r3-5

Next step: I commit the merged data to branch “b1”, go back to the trunk, change files again, and perform another merge to branch “b1”. Let’s see what the “svn:mergeinfo” property looks like afterwards.

mbp:b1 gerhard$ svn commit -m "merged latest changes from trunk"
Sending .
Sending file1.txt
Transmitting file data .
Committed revision 6.
mbp:b1 gerhard$ cd ../trunk
mbp:trunk gerhard$ vi file2.txt
mbp:trunk gerhard$ svn commit -m "added text to file2.txt"
Sending file2.txt
Transmitting file data .
Committed revision 7.
mbp:trunk gerhard$ cd ../b1
mbp:b1 gerhard$ svn update
At revision 7.
mbp:b1 gerhard$ svn merge file:///Users/gerhard/mytest/svn/repo/trunk
--- Merging r6 through r7 into '.':
U file2.txt
mbp:b1 gerhard$ svn commit -m "merged latest changes from trunk"
Sending .
Sending file2.txt
Transmitting file data .
Committed revision 8.
mbp:b1 gerhard$ svn propget svn:mergeinfo
/trunk:3-7

Well, works as expected. Subversion knew, that only revisions 6 and 7 had to be merged into branch “b1”. The property “svn:mergeinfo” has been updated and now shows that revisions 3 throughout 7 have been merged.

I change “file1.txt” in branch “b1” again and then merge data back from branch “b1” into the trunk. At this point it’s important to use the “–reintegrate” option of “svn merge”. Merging a branches work back into the trunk works just one time (with this method, at least).

mbp:b1 gerhard$ vi file1.txt
mbp:b1 gerhard$ svn commit -m "changed some text in file1.txt"
Sending file1.txt
Transmitting file data .
Committed revision 9.
mbp:b1 gerhard$ cd ../trunk
mbp:trunk gerhard$ svn update
At revision 9.
mbp:trunk gerhard$ svn merge --reintegrate file:///Users/gerhard/mytest/svn/repo/branches/b1
--- Merging differences between repository URLs into '.':
U file1.txt
U .
mbp:trunk gerhard$ svn commit -m "merged branch b1 back into trunk"
Sending .
Sending file1.txt
Transmitting file data .
Committed revision 10.

Finally, branch “b1” can be deleted, as no more changes should be done there. This way it will not distract anyone (history is not lost, of course).

mbp:trunk gerhard$ svn delete file:///Users/gerhard/mytest/svn/repo/branches/b1 -m "removed branch b1"
Committed revision 11.

This was a simple example of how to create a branch, keep it up-to-date and finally reintegrate it into the trunk. With Subversion 1.5 these typical steps became much easier and safer.

For further reading, I recommend the Subversion Book’s chapter Branching and Merging.

I have been using Adobe Premiere Elements for some years now – initially I had version 1 and upgraded to version 3 about 2 years ago. Version 3 (currently the up-to-date version 3.0.2) is what I still use to edit my home videos (usually vacations or family events).

Well, I’m really happy with Premiere Elements 3 – it offers me all the functionalities I need. But, there was just one little thing that annoyed me a lot: when placing video transitions between two clips, Premiere Elements 3 blocked for three to four seconds, which is terribly long in cases where you want to add a lot of transitions…

The same problem occurred when I wanted to add DVD scene markers to a movie. Endless delays…

The incredible thing is, that I have used Premiere Elements 3 for about 2 years now and it seems I got used to this problem. OK, I guess I did less video editing and enjoyed it less…

Yesterday evening I played around with Premiere Elements and delays surprisingly were gone! It worked like a charm – placing a transition took zero seconds, absolutely no delay!

Today, I started Premiere Elements again and, well, delays were back. So I investigated to find out what made it work so well yesterday. Finally the solution was: Usually I always edit my videos in “timeline” mode. Yesterday I switched to “sceneline” mode for some experiments. It seems that this switch to sceneline mode solves all delay problems… today I just had to switch to sceneline mode and then back to timeline mode. Delays were gone again. I don’t even had to do any actions in sceneline mode – just switch there and back to timeline mode and then work in timeline mode as always.

I really don’t have any idea why this is so, but I’m happy that I finally found a solution to this delay problem. These delays were so annoying…

So, if you experience these delays, too, try to switch to sceneline mode and back. Chances are that this will stop your pain.

Subversion 1.5 has been released some months ago (June 2008) — so it’s time to take a closer look at it. For my daily work I am still using Subversion 1.4 (well, I updated my client to 1.5 some weeks ago, but didn’t use 1.5 functionality so far).

I’ll take closer looks at new Subversion features and try them out with examples in my next posts. As for now, I just post two useful links for further reading about Subversion 1.5:

What’s New in Subversion 1.5 (tigris.org)

Subversion Book

Collabnet