Monthly Archives: August 2011

Subversion tip: Update works, but commit fails

You use devZing Subversion hosting for your project. The time comes to sync your file(s) and a problem arises when you do so. I mean, the update worked. But it fails to actually commit. The error message “Authorization failed” appears. What is going on? How can there be an authorization failure?

Well, the problem is simple and the solution is simple, too.

Here’s the problem: Subversion has a quirk. It lies in the commit process.

When you create a working copy, you can accidentally put in a technically incorrect URL and it still works. The checkout allows the case of the characters to not match the “official” URL. Because the update command is case in-sensitive, whereas the commit command is case sensitive, Subversion allows the error. For example, your original (and “official”) URL may be “svn://“. But when you enter the URL in the checkout command, the command which creates the working copy, you accidentally enter everything lowercase. You put in “svn://“. That’s easy enough to do.

But the commit doesn’t recognize this URL and rejects it with an “Authorization failed” message. It only accepts the exact original.

So check your original repository URL.



Make sure everything is exactly as it shows in the URL column.

The solution is simple indeed. Just check the URL of your working copy.

Subversion Tip: Fix Missing Date and Author in Svn Log

If you are trying to use the svn log command and the output is missing the author and date fields like the following example:

c:working> svn log
r8 | (no author) | (no date) | 1 line
r7 | (no author) | (no date) | 1 line
r6 | (no author) | (no date) | 1 line
r5 | (no author) | (no date) | 1 line
r4 | (no author) | (no date) | 1 line
r3 | (no author) | (no date) | 1 line
r2 | (no author) | (no date) | 1 line
r1 | (no author) | (no date) | 1 line

More than likely your Anonomous Access is set to Read.

Change this to None to prevent this problem.

If you are using a client like TortoiseSVN you may need to clear any cached logs.

In TortoiseSVN go to the settings screen and look for the Cached Repositories node. Then select and delete the repository you just fixed.

Be sure and check out our subversion hosting service.

Avoid Spam: Make Bugzilla Private

Bugzilla is a great bug tracking system. But when you open an account, it doesn’t automatically have your privacy in mind. In fact without taking a couple short steps, your email addresses will actually be visible to the public. This is an open invitation to spam.

Consider what the Privacy Notice email says:

PRIVACY NOTICE: Bugzilla is an open bug tracking system. Activity on most bugs, including email addresses, will be visible to the public. We recommend using a secondary account or free web email service (such as Gmail, Yahoo, Hotmail, or similar) to avoid receiving spam at your primary email address.

Yikes! Why use the software at all? I have to set up new email accounts just to accommodate all the spam I’ll get?

Don’t despair. There are only a couple steps you need to take to make your Bugzilla private.

From the Bugzilla Main Page, follow this..

Administration -> Parameters -> User Authentication

Scroll down the page to this field:

Hit the “ON” button. (You want to turn on the requirelogin feature.)

Next find this field:

Delete the contents of the field. (Delete the “ .* “)

There you go! Two easy steps.

Spam can be a headache. As an administrator you want to keep all activity on Bugzilla private, for yourself and all involved with your project. Take these two steps first.