Month: January 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.

[Updated 2015-02-02]

Purpose of this post:

To demonstrate how and why to merge a branched project under Subversion Source Control back with it’s root project.  The documentation provided with TortoiseSVN, while extensive, is confusing and vague.  Many of the actions described both in the documentation and in the TortoiseSVN GUI are not clear whether they are acting on the local drive or on the server.  The terminology is inconsistent.  This post makes it clear.

[GARD]

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 perform a merge operation on a Windows client with TortoiseSVN to a Subversion trunk.
• has a folder somewhere on their hard drive with source files in it that are already being controlled by Subversion.
• Has already performed a branch, is working with the branch, and now would like to merge that branch back to the server folder from which it was originally branched.

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 perform a merge operation.
• talk about any particular programming language.
• try to convince you that Subversion is better or worse than any other version control system.

What is “Merging”?

For the purposes of this discussion, “Merging” is the act of getting a branched copy of a project on the Subversion server to merge back into the original folder on the server from which it was originally branched.

How to Merge:

[GARD]

1. From your local, working folder that’s linked to your branched project on the Subversion folder, perform a commit to get all your changes checked back into your branched copy on the server.
2. Do an update to ensure your local, working copy has the latest files from the branched copy on the server.
3. If you don’t already have a local folder that is linked to your Subversion server’s trunk folder of your project (or the original server folder from which your branch was originally branched), then make a new, local folder and link that to your Subversion server’s trunk folder.  (You will be performing the merge from the local working copy of the server’s trunk folder).
4. Right-click your local, working folder that’s linked to your server’s trunk folder and choose TortoiseSVN, Merge.
5. Choose “Merge a range of revisions”.
6. Click “Next”.
7. In the text box “URL to merge from”, make sure your server’s branched folder is entered.
8. Click “Show Log” and select all versions (not just the latest), then “OK”.
9. Put a check mark next to each version in your branch that needs to be merged to the trunk (any version # that’s greater than whatever version # you branched from the trunk).
10. Click “Next”.
11. Click “Merge”.
12. Wait for it to complete, then click “OK”.
13. This merged the branched copy in the server to your local working copy of your trunk folder.  It’s still not yet on the server’s trunk folder.  Rick-click your local working copy of your trunk and choose “Commit” to push all the changes up to the server’s trunk folder.
14. Do an “Update” on your local working folder that’s linked to your server’s trunk folder to ensure you have all the latest code (not just the latest from the old branched copy).
15. Delete your branched folder on the server if you’re done with it.
16. Delete your local working branch folder too, if you’re done with it (You should now be working with your local working copy of the server’s trunk folder).

[GARD]

That’s it.  Your local working copy and your server’s trunk folder now have the latest changes from your branch.

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

• Subversion Branch: How To

• 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.

Purpose of this post:

To demonstrate how and why to branch a project under Subversion Source Control.  The documentation provided with TortoiseSVN, while extensive, is confusing and vague.  Many of the actions described both in the documentation and in the TortoiseSVN GUI are not clear whether they are acting on the local drive or on the server.  The terminology is inconsistent.  This post makes it clear.

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 perform a branch operation on a Windows client with TortoiseSVN to a Subversion server.
• 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 perform a branch operation.
• talk about any particular programming language.
• try to convince you that Subversion is better or worse than any other version control system.

What is “Branching”?

Branching is when you have a project in a version control system and you want to split off (or clone) a copy of it and work with that copy, making changes (commits) to it over time.  At some later point, you may (or may not) decide to merge those changes back into the main (trunk or head) project.

Part of the “Best Practices” of Subversion usage is to always create a branch when you start working on a new feature or version of a product.  When you’re done, you then merge your branched copy back into the main copy, then delete your branch.

How to branch:

1. Make sure your server project has a trunk folder and a branches folder.
2. Starting with your local copy, commit (takes your local changes and uploads them to the server) all of your changes now (It’s important that your local copy and your server copy are both up to date).  This local copy should be linked to your trunk folder (or whatever server folder you want to branch from).
3. Now, do an “update” (which gets the latest version from the server).
4. Right-click your local folder, choose “TortoiseSVN”, then “Branch/Tag”
5. In the “To URL” text box, you should see the current server folder that your local folder is linked to.  Change it to the new (yet to exist) branch folder you want your branched copy to exist in on the server.  In other words, in that text box, delete the work “trunk” and type the word “branches/” then the name of the branched copy.  This will cause a new folder to be created in the server repository under the “branches” folder.
6. In the lower left, check the box “Switch working copy to new branch/tag”.  This will cause your local folder that you’re working from to be unlinked from the trunk folder from the server and then linked to the new branched copy on the server.  All future commits will go to the branched copy on the server and all updates to that local copy will come from the branched folder on the server.
7. Click “OK”.

You will now have a new subfolder on the server repository under your branches folder on the server.  Your local copy is no longer linked to your server’s trunk folder.  It’s now linked to your newly created subfolder in the repository under the branches folder on the server.

If you now make changes to your local copy, then commit, your changes will be submitted to your branched copy on the server.  The trunk folder on the server will not receive your commits.  Further, any updates (downloading from the server) will come from your newly created folder on the server under the server’s branches folder.

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

• 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.

 

Thought I’d post this online just in case someone can use it:

Here’s the text from the coupon (do not hold ME accountable for any of this.  I’m just copying the Dish Network text.  If you have a problem with this deal, contact Dish Network)

Sign up for DISH Network today and get $30 off your first bill*

Promotion Codes:

Ordering Direct:	DIRCDFDHA
Ordering Retailer:	RETCDFDHA

PACKAGES STARTING AT

$24.99/mo	LOCK IN	FREE	FREE	FREE
Reg Price $39.99/mo	YOUR SAVINGS FOR A YEAR	HBO (8 channels) & Showtime (10 channels)	DVR Upgrade ($5.98/mo DVR Service fee applies)	— Standard — Professional Installation in up to 4 rooms

*Requires Agreement.  Restrictions apply, see reverse for details.

Simply use this certificate number to get the $30 credit on your first bill.	Get DISH Network Today! Call: 1-888-253-5853
DRC88724863	Click: www.dishnetwork.com
OFFER EXPIRES 1/31/10	Visit: your local participating Retailer

Click image below to enlarge.

 

The Microsoft – Wireless N Network Adapter for Xbox 360 (PHD-00001) pictured below:

provides wireless connectivity between your XBox 360 console and your home wireless network.  It’s wireless N compatible and is also backward compatible with 802.11a, b, & g.  If you don’t have a wireless-N adapter, you won’t get the high speed benefits of this device.

This device is designed specifically for an XBox 360 console.  It’s not likely going to work with anything else, though I’ve not yet tried it on a PC.  Microsoft certainly won’t provide any technical support if you’re trying to use it on a PC or anything other than an XBox 360 console.

Speed:

I haven’t tested the actual throughput of this device yet, but I did run a speed test using the XBox’ 360’s Media Center speed test.  In prior tests with an 802.11g wireless adapter (also from Microsoft), the speed test shows speeds about halfway between what’s needed for SD (Standard Definition) TV video and HD (High Definition) TV video.  All my video tests with prior networking came up short when trying to play HD content.  It always started skipping both the audio and the video.  SD video was always good.  With the new 802.11n wireless adapter, the graph for the MediaCenter test spiked up well above the HD line and capped at the very top of the graph.  This was good news.

I then played some actual HD video by streaming it from my PC upstairs to my XBox 360 through the wireless N network.  The results were mixed.  Video that I had recoded after editing in Windows Movie Maker for Vista played well, with an occasional frame rate drop when the action was rapid.  But, when playing video files that were dumped directly from my HD camcorder to the hard drive, the video would either hang or the frame rate would drop to very low rates.  For example, for Knoxville’s Boomsday fireworks show, it looked like it was down to about 5 to 10 frames per second (when normal video is about 30 fps).  It’s still a major improvement, but still not capable of playing the full HD content from my camcorder.

Ease of set up:

If it hadn’t have come with set up instructions and a set up DVD, it would have been much simpler to set up.  The instructions said to insert the disc, power off the XBox 360, then power it back on, then follow the installation instructions, then hook up the wireless controller.  When I inserted the disc into my XBox 360, it simply said there was a mixed media disc in it.  After shutting down and starting back up, same thing.  There was no software installation and nothing happened.  So, I simply just plugged in the new wireless N adapter and it just worked.  Granted, I had already set up my XBox 360 console with the older XBox 360 wireless adapter, so my console already knew the name and password to my wireless network.  The only set up I needed was to detach the old adapter and attach the new one.

Cost:

This product retails for $99, but Best Buy had it on sale for $89.  You’re not likely to find it anywhere else for a better price.  XBox 360 hardware generally is always sold at full retail.  If you can find it on sale, that’s the time to get it.  It’s a rare event.

Benefits:

I can’t imagine this would provide much (if any) benefit for gaming though.  I use my XBox 360 console for showing home videos by archiving all of my home videos on my primary PC and streaming them to my big TV downstairs using the 360’s Media Center Extender capability.  Most people aren’t aware of this feature and it’s a highly underused and great feature.  If you’ve got a Windows Vista or Windows 7 PC (or an older Windows XP Media Center PC), you can use that PC to host and archive all of your digital media (videos, music, photos).  Your XBox 360 (as well as the original XBox) is a Windows Media Center Extender, which means, it can connect to a Windows Media Center PC and stream the content strait from your PC to your TV.  This makes it MUCH easier to show your home videos.  You don’t have to mess with finding and hooking up your cables, finding the right tape, pulling out your camcorder, etc…  It’s essentially Video On Demand for your own stuff.

If you don’t have HD content to show, then this XBox 360 wireless N adapter probably won’t provide you any benefits over the older adapter.  But, if you’re buying a new adapter, this is definitely the one to get because it’s the same price as the older one, so you might as well get this one.  I’m not even sure the older one is sold by Microsoft anymore.

Conclusion:

If you don’t already have wireless networking for your XBox 360 console and you need it, this is the adapter to get.  If you already have wireless connectivity with your XBox 360 console and it works just fine and you don’t shoot home videos in HD yet, you won’t see any real benefits with this higher speed adapter.

I recommend this product if you meet any of the following:

• You don’t already have wireless connectivity and you need it.
• You already have slower, wireless connectivity, but you have now or plan to have in the future, HD video content.