Day: January 17, 2010

 

Heads up to MySQL and .NET developers.  MySQL appears to have a bug in the .NET connector code.  If you’re using typed datasets and drag a table from the server explorer onto your data set designer, it will appear to work (and it does), but it also generates SQL code with the name of the database hard coded in front of the table name.  This is not a problem if the name of your development database is the same as your test and production databases.

If your production or test database has a different name than your development database (the database you were connected to when you dragged the table or other DB object from server explorer onto your data set design surface), then when you change your connection string to use your test or production database with a different name, it will fail, even if you explicitly specify the name of your production or test database in your connection string, the hard coded development database name is STILL in the generated SQL and your code will fail to execute.

The solution is to manually remove the hard coded database name prefix from all of the generated SQL in your typed data set.

If you’re writing code that uses Apache Directory Server (a free, open source LDAP server), you may get the error “service unavailable” frequently.  Apparently, there’s an issue with making 2 consecutive calls quickly to the ApacheDS server.  If you put a delay of about 1/2 second between calls, this will usually work around the problem.

ApacheDS does not appear to be capable of handling rapid requests to it.

 

ApacheDS is a free, open source LDAP server.  If you’ve ever heard of Microsoft Active Directory, it serves the same purpose of that, without requiring you to purchase a full blown Windows Server license to gain that capability.

There’s an issue with it though.  If you’ve ever noticed that after you change a password to an account in ApacheDS, that both the new AND the old password continue to work?  There is some problem with ApacheDS, probably a caching issue, in which the old password is still valid for up to around 2 minutes afterwords.

If you’re writing unit tests with tools like NUnit or anything else and your test code creates a new account, changes the password, then validates the password is changed by attempting to login with the old password, you’ll notice that test will fail almost all the time by allowing a login with the old password.  You’ll need to put in a timer after the password has been changed.  I recommend a loop of 90 iterations of 1 second waits.  At the end of each 1 second wait, attempt to login with the old password.  Continue this for up to 120 tries until the old password fails or until the 120th try.  At the 120th try, if it still logs in with the old password, give up and call it failed.  If it fails at or before the 90th attempt, call the test a success.

Knowing that there is a delay will save you hours of research.  Rest assured, the problem is NOT in your own code.

Purpose of this post:

To demonstrate how to disconnect Subversion from controlling a folder on your local drive using TortoiseSVN.  The commands in TortoiseSVN are very vague and in this case, counter-intuitive.

Intended Audience:

Programmers new or somewhat new to Subversion Version Control System.

Target Platform and Tools:

This will be on a Windows client platform (server platform is not relevant to this discussion) using the TortoiseSVN Windows Shell extension (It adds a right-click menu to folders in Windows Explorer).

Expectations of the reader:

It’s assumed that the reader:

• has already downloaded and installed TortoiseSVN.
• has access to a Subversion server.
• Can perform basic operations on Subversion with TortoiseSVN.
• understands the basic concepts of version or source control (repository, check in (commit), check out (update), etc…)
• is a programmer or system administrator.
• is reading this post to learn how to unlink a local folder from a Subversion repository, while performing the operation on a Windows client with TortoiseSVN.
• has a folder somewhere on their hard drive with source files in it that are already being controlled by Subversion.

What this post does NOT do:

• Teach you about the basics of version control (or source control).
• Teach you how to install any components of any software.
• anything other than provide what you need to know to disconnect a local folder from a Subversion repository.
• talk about any particular programming language.
• try to convince you that Subversion is better or worse than any other version control system.

What is “Unversioning” or “Unlinking” or “Disconnecting”?

Neither of these are “official” terms.  As a matter of fact, there does not appear to be an official term for this type of operation.  In short, what we’re talking about here is the act of stopping a local folder from being connected to a Subversion repository in any way.  You’d think this would be simple to find, but it’s not.

How to Unversion or Unlink or Disconnect:

1. In Windows Explorer (not Internet Explorer!!!), right-click your local folder that’s currently under Subversion control that you wish to no longer be under Subversion control.
2. Choose “TortoiseSVN”, then “Export”.
3. The “Browse for folder” dialog box comes up.  Use that to find the SAME folder you just right-clicked on then click the “OK” button.
4. TortoiseSVN will recognize that it’s already versioned and will offer you the opportunity to unversion it with the following dialog box:
   • 
5. Click “Yes”.

Your folder will no longer be versioned or linked to subversion.  It’s now just another folder on your hard drive.

Related articles (articles that aren’t links have not yet been written):

• Subversion Branch: How To

• Subversion Merge: Merging your working branch back into the trunk.

• Subversion: Linking a local folder to a Subversion folder on the server.

• Subversion: Unlinking a local folder from a Subversion folder on the server.

• Subversion:  Checking out.

• Subversion:  Checking in.