Removing ignored files from a git repository

When I am using TFS, Visual Studio manages the files which should not be committed. So when I create a git repository I often forget to add the .gitignore file. The first reminder I get about my oversight is when I see all the DLLs being added during the first commit.

Today I decided to find out how to clean up the repository. First I added this .gitignore file to my repository:


Then I searched the internet. The first hit from Google was this post by Aral Balkan. The content and the comments provided me with all the information I needed to manage the git repository.

Searching and cleaning the repository

An instance of a git repository can be thought of as an isolated file system. As such commands can be run against it the same way as a normal file system.
The first command I needed was git ls-files which works in the same way as ls. The command git ls-files -i -X .gitignore lists all the files in the repository which would have been excluded had I remembered to set the .gitigonre.
Removing a file from git is done using the git rm. As git is a versioned file system there is the file on disk and a reference to that file in the index. The command git rm --cached will remove the reference from the index but leave the file on disk.

A script to do that

Manually removing each file from the index would take some time. It would also go against all of my computing instincts. The job needs a script.


Here I simply loop round the results from git ls-files sending each one to git rm. I am sure there are many ways to achieve the same result but this method worked well for me. I am using git bash and Windows.

Reset Remote Desktop Connections

Being able to connect to the desktop of another server is an essential part of most developers working day. Whether it is to configure IIS or to kick of a deployment, starting up the Remote Desktop Connection client is often the quickest way to complete the task.

Unfortunately the basic configuration only allows for three connections at any one time. Also, if someone just closes the client, their connection is not cleared. It will hang around in a disconnected state until someone connects to the physical machine to clear any unused connections.

There are two DOS commands which solve this problem. The oddly named; QWINSTA and RWINSTA.

qwinsta /server:SuperServer

The displayed list will include the session Id which you can use with the next command, rwinsta, to reset the sessions. Type the following to reset session 1 on SuperServer:

rwinsta 1 /server:SuperServer

Be sure to pick sessions with the state “Disc” as connections marked as “Active” my really be active.

Often the simplest tools yield the biggest gains. The discovery of these two commands has saved many hours of work. I no longer have to go through the IT support process and have an engineer go to the physical machine.

Running Selenium tests in Visual Studio

Troublesome testing

I found the amount of time I spent manually testing forms as part of my development process painful and thought there must be a better way of doing this task. The forms are tightly coupled to the database so any refactoring becomes a risky process due to the lack of unit tests. One answer I found that helped me is the http://seleniumhq.org/ web testing framework from ThoughtWorks.

You can download the example code for this post here: http://keithbloom.s3.amazonaws.com/Selenium.Example.zip The only requirement is that you have Java or greater on your PC.

The framework is built around a language called Selenese which executes actions in a web browser. There is a client library available for .Net, so the tests can be run in NUnit or any similar tool. For the NUnit integration to work you have to be running the Selenium RC web server to host the test and a web server for the ASP.Net page being tested.

This could be a lot of work upfront just to run some tests. So I have written some helpers to configure the environment automatically.

Web server

The development web server which ships with Visual Studio (once called Cassini) is a perfect tool for hosting the ASP.Net page under test. An instance is started for the test suite with a hard coded port of 8085 and the URL is set to localhost. As all the projects live at the same level in my project tree I am able to hard code the path as well.

Selenium RC

The process that hosts the tests is a Java based application called Selenium RC. When a test is run in NUnit, the Selenium client library sends Selenese commands to this process over HTTP. When the test suite first runs, I start a Java process and point it to the Selenium RC jar file, this will only get closed when all the tests are finished.

Selenium Runner

The helpers are combined by an abstract class which starts the Web Server and Selenium RC process so any test class that derives from this will automatically have the testing environment configured. The only data required by implementors is the name of the project under test:

Speedy

I have been using this for a week now. At first just as a means to run through the forms quickly. However, I have found other uses for it. I have started adding asserts for common scenarios. One Selenium command that is proving useful to me is selenium.GetHtmlSource() which returns a string of the full source code. This is enabling me to run a test and see the source appear in the Output window and then to check for the presence of certain items. I have used this method the check that certain Omniture tags are being generated:

I am happy with the addition of UI testing to my development process. Here it helps to deal with legacy code which requires some work. It is now possible for me to start refactoring which is something that can only be done with this kind of test coverage.

Exclusion list for Tortoise SVN

I use ReSharper, an amazing extension to Visual Studio and one which seems to be on most developers default tool list. I have now started using Subversion and Tortoise for some personal projects which means I have to manage my own file exclusion lists, specifically ReSharper which quickly turns a 100KB project in to a 4MB one.

So here is my TortoiseSVN global ignore pattern:rn:

_ReSharper*
*.resharper
*.dll
*.exe
*.ncb
*.o
*.obj
*.pdb
*.projdata
*.pyc
*.scc
*.suo
*.user
*.vspscc
*.webinfo
*proj.user
bin
obj
temp
tmp
user.config

With this set on all clients any files matching this pattern will have to be manually added to the repository.