Dave Donaldson

Test Naming: To Underscore or Not To Underscore

Dave — Tue, 06 Jan 2009 16:41:12 GMT

As I’ve mentioned a few times in this space before, I am a freak when it comes to naming things, so much so that James even gave me the nickname “The Name Nazi” a couple years ago. But in my ever-expanding quest to constantly challenge the way I think, I’ve been peeking at the conventions being used by BDD’ers where underscores tend to be used for test names and fixtures.

As someone with a constant eye on the public API design of everything, I’ve never been a fan of using underscores in method names, and when it comes to public APIs, I definitely believe underscores should not be used. But seeing some of the work Sean and Leon are doing with certain things internally here at Telligent has me re-thinking how I write tests, in particular how I name my tests (this re-thinking is why you hire people smarter than you, but that’s a topic for another day).

You see, with BDD, test names tend to get very long because they describe behavior very explicitly. Many believe that because of this, using standard Pascal-case for test names leads to less readable names than if you used underscores. Take for example the following three test method names:

public void CanGetSuccessReturnCodeFromBlogsEndpoint()
public void CanGetSuccessReturnCodeFromBlogEndpointById()
public void CanGetSuccessReturnCodeFromBlogPostEndpointByKey()

All three of those test names are pretty descriptive and kind of lengthy. Now look at them with underscores:

public void can_get_success_return_code_from_blogs_endpoint()
public void can_get_success_return_code_from_blog_endpoint_by_id()
public void can_get_success_return_code_from_blog_endpoint_by_key()

Do you find these more readable than the Pascal-cased names above? I’ve always considered underscores a bit of noise that is distracting in code, but in this case, I’m starting to reverse that line of thought, at least in terms of test names. For a different look, here’s how the names appear in NUnit GUI:

So for me, I’m going to give underscores in test names a shot and see if it sticks, but what I really want to know is what *you* think. Which way do you prefer, and why?

Similar Posts

My Top 5 Posts of 2008, Sort Of

Dave — Wed, 31 Dec 2008 14:39:42 GMT

I’ve never actually written a “Top X Posts” post to end the year before, so I figured, what the heck, I’ll do one this year. As Phil points out, “I find that somewhat narcissistic, so you know I’m going to do that”.

And notice I said “sort of” in the title of this post. That’s because on October 1st I switched blog engines (from Subtext to Graffiti) and hosting providers (from DiscountASP to OrcsWeb), so instead of trying to be completely accurate and aggregate stats across both both engines and both hosting providers, I’m taking the lazy approach and am using only the Top 5 posts since making the switch.

My guess is these are a pretty good projection of the year anyway, so here are my Top 5 posts for 2008 (sort of), according to Graffiti for the reporting period Oct 1 – Dec 31:

NHibernateRepository. This post is over two years old but still gets plenty of traffic. The codebase is a bit outdated now; hopefully I can update it soon to take advantage of stuff I’ve learned since then.
Use a Single Web.Config for IIS6 and IIS7. The title pretty much says it all.
Charcoal Visual Studio Settings. After avoiding dark-background settings for so long, I finally found a theme I like to code in.
Zune Desktop Theme. Another post that’s a couple years old, but helps show how many people out there still use Windows XP.
Bloggers Holiday Charity Challenge. This is me taking part in ScottW’s challenge to spread some love this holiday season. I’ll be posting my results of this in the next few days.

And that’ll do it for 2008. See you on the flip side.

Similar Posts

Why Do Some 64-Bit Apps Install to C:\Program Files (x86)?

Dave — Tue, 30 Dec 2008 15:11:00 GMT

I’ve been running 64-bit Vista for awhile now and have experienced almost zero issues. One of the nice things about 64-bit operating systems is their ability to continue to run the thousands of 32-bit applications just fine. In Vista’s case, it even goes so far as to segregate the installation of 32-bit apps and 64-bit apps into separate locations: 64-bit apps default to C:\Program Files while 32-bit apps default to C:\Program Files (x86). Heck, you can even run 32-bit and 64-bit versions of the same app side-by-side.

But have you ever went to install a 64-bit app and notice it default to the C:\Program Files (x86) directory? I recently stumbled into this when installing Virtual PC 2007 (x64) after rebuilding my desktop. During installation I noticed its default location to be C:\Program Files (x86) which I found very odd. Shouldn’t it be defaulting to C:\Program Files instead? Should I change the default location? Am I installing the right version?

Because of this, I posted a few tweets that said something along the lines of, “Why didn’t Microsoft change the default install directory for Vistual PC 2007 x64? Was it really that hard?”. Well, later on I was straightened out by my old DevelopMentor colleague Brian Randell, who sent me a direct message clearing up my confusion. Basically Brian told me that Virtual PC 2007 x64 is in fact a 32-bit application, but with 64-bit drivers.

So there you go. It didn’t occur to me that the “x64” in the title could just mean 64-bit drivers. I assumed it meant the app is a true 64-bit app. My mistake, but at least I learned something.

Similar Posts

UI Design First, Then Everything Else

Dave — Mon, 29 Dec 2008 22:58:54 GMT

One of the things I wanted to do while on Christmas break was to begin building a custom web site for our travel baseball organization. The existing one is outdated and horribly designed and while I’m by no means the World’s Greatest Web Site Designer, I’ve been around long enough to have an understanding of what good design looks like.

So to build this new web site, I’m taking a different approach than what I’ve normally done. Instead of starting from the database and working my way “up” to the user interface, I’m beginning with the UI and will work my way “down” to the storage level (which may end up in Azure SQL Services, just for kicks). The former approach has usually worked out just fine, as it made sense that the UI would just “plug in” to the business/services layer and all would be well, but I’m trying to expand how I think about design, so I thought I’d flip my thought process and see how things go.

As I start on the UI design, I’ve decided to do it entirely with paper. I know that Balsamiq has been making some headway with online mockups, but I tried it and although it’s cool and slick, it still doesn’t feel as natural to me as manually drawing on a piece of paper (or whiteboard). So what I’ve done is put all of my UI mockups in a spiral notebook (remember those?) for easy access whenever I need it (sitting on the couch, laying in bed, wherever). Here’s a sample of a couple pages:

It’s been nice to have all these UI mockups and other design thoughts located in a single binder. Everything is right there together for quick and easy reference, and I can scribble in the margins to note certain behaviors and whatever else comes to mind. Ultimately the way I want this to work is to take a mockup and code it from the UI on down, thus implementing the site in end-to-end slices that eventually make up the whole site.

Another reason I wanted to start with the UI first is because I think it will help flush out a better API with regards to the business and data layers. I’ve always used tests to flush out API design in those layers, and while I’ll still write tests here, I think having the UI up front will help even more.

So what do you think? Have you ever taken this approach? If so, how did it go? Was it better than going bottom-up?

Similar Posts

Using svn:externals to Manage Project References

Dave — Sat, 20 Dec 2008 19:33:52 GMT

Almost every project I've ever worked on has had dependencies on external projects, whether it was web services, components, or libraries, and working at Telligent is no different. But what's been interesting is how we manage internal dependencies, especially with regards to building Community Server.

The core Community Server product is developed using a single Visual Studio solution that contains many projects, and for the projects in that solution, we use project references and all is good. Where it gets interesting is when Community Server needs something outside of the solution, but still built by us.

The Infamous lib Folder

Like many projects, we used to have a folder named lib, and the original intent of the lib folder was that it would contain all third-party assemblies used by Community Server (things like RSS.NET and CookComputing.XmlRpc). Then to reference those third-party assemblies, we simply used a file reference from the proper project(s) and life was good.

However, Community Server not only depends on third-party assemblies, but also some internal non-Community Server specific assemblies. These are things we internally refer to as the Telligent.* assemblies; assemblies that can be used cross-product, such as Telligent.Caching and Telligent.Common. Those assemblies are not part of the Community Server solution and are maintained separately.

What we used to do with these other assemblies was to also add them to the lib folder, which worked for awhile, but was problematic. For instance, if Telligent.Caching was updated, it was too easy to forgot to put the updated version in the lib folder, thus increasing the risk that the wrong version of Telligent.Caching would be shipped with Community Server. And of course the problem was compounded for each additional dependency, and more risk was incurred. We tried using post-build events to help manage that process, but it was kind of messy and people would still forget to check-in the updated versions to the lib folder.

FallenRogue to the Rescue

As we marched closer to the CS 2008.5 and CS Evolution releases, it became clear that our Subversion repositories needed some restructuring. The overall structure wasn't necessarily bad, but there were several things in the wrong place and/or that needed to be consolidated.

During this time Leon and I were brainstorming about what problems we were having and what changes needed to be made, with one of those changes being how we managed those pesky project references. And if I remember correctly, Leon asked "Why aren't we using svn:externals?" to which I replied "Huh?" :-)

After much discussion, I was having problems wrapping my head around what Leon was explaining because I couldn't quite visualize it; what we needed was for the two of us to stand at a big whiteboard and draw it all out. So, having a large whiteboard in my home office, and Leon being only an hour away, he drove to my place a few days later (with Dan H in tow) to spend a day working on this. What we hashed out that day with svn:externals has made a huge improvement in how we manage our project references.

3rdParty, Assemblies, and References, Oh My!

The first thing we decided was to eliminate the lib folder, at least in its current form. Instead, we would have a folder named 3rdParty that would contain *only* true third-party assemblies. Any assembly we use that is not ours goes into the 3rdParty folder. Simple enough.

That change leaves us with the question of where we put the other non-Community Server specific assemblies, and this is where svn:externals comes into play. So just what is svn:externals exactly? According to this section of the SVN Book its:

"An externals definition is a mapping of a local directory to the URL — and possibly a particular revision — of a versioned resource."

What we wanted to do was designate a folder that would contain all of our other references, but set it up in a way that would automatically keep those other references up-to-date; this is accomplished using svn:externals. To see it in action, first look at the following folder structures:

Trunk of Community Server

Trunk of Telligent.Caching

Trunk of Telligent.Common

Notice how all three projects have an Assemblies folder, while Community Server has an additional folder named References. These are defined as such:

Assemblies: Contains the compiled output of the project. For example, when the Telligent.Caching project is compiled, a post-build event runs that copies all of its dll files to its Assemblies folder, and those assemblies are check-in to Subversion. The Assemblies folder is what is used by svn:externals.
References: Contains the assemblies for all non-third party references. For example, the References folder for Community Server contains the assemblies for Telligent.Caching and Telligent.Common, among others.

If we expand the References folder for Community Server, this is what we see:

Each folder in References corresponds to the Assemblies folder of its respective project. For example, the Telligent.Caching folder in References is linked to the Assemblies folder we saw above in the Telligent.Caching project. Thus, the Telligent.Caching folder we see in References contains the exact same dll files as the Assemblies folder in the Telligent.Caching project. This is svn:externals in action.

Setting Up svn:externals

To set all of this up, first create a References folder and add it to Subversion. Leave it completely empty and don't put anything else in it; it gets its contents from svn:externals later. Once it's part of Subversion, you can apply svn:externals to it by (using TortoiseSVN) right-clicking on it, going to TortoiseSVN, selecting Properties, and clicking New. If you then click the dropdown list in the top right corner, this is what you'll see:

There are all kinds of Subversion properties you can use, but when you select svn:externals, you simply enter key-value pairs in the Property Value textbox. More accurately, svn:externals is a collection of one or more key-value pairs. The svn:externals property for the References folder in Community Server looks like this:

If you look closely, each entry is simply a name (the key), followed by a space, followed by a fully-qualified Subversion URL to the appropriate Assemblies folder (the value). For example, Telligent.Caching is setup with the name "Telligent.Caching", followed by a space, followed by "svn://svn.telligent.com/Product/Telligent/Telligent.Caching/Trunk/Assemblies".

Note that the name in the key-value pair will be the name of the folder for that project that gets put into the References folder.

Once you've entered all key-value pairs and click OK, you must do two things:

Commit those changes to Subversion for the References folder, then
Re-get the References folder. At this point when you re-get References, it will get populated with the contents of the folder(s) it was linked to with svn:externals. In our case this is the contents of various Assemblies folders of several other projects.

Essentially what's happening is that svn:externals acts as a linker of sorts, so that when you update your local working copy, Subversion will ensure the References folder is automatically updated with the current revisions of the folders defined in the svn:externals property.

You can even setup svn:externals to pull only specific revisions instead of the most current. For example, let's say recent changes to Telligent.Caching broke something in Community Server and, because of other factors, can't be addressed right away. But because we knew the previous revision worked fine, we can update svn:externals on the References folder to pull that specific revision for the Telligent.Caching assemblies. Simply edit the Telligent.Caching key-value pair in svn:externals of the References folder to include a revision number, like so:

Notice the -r490 in the Telligent.Caching key-value pair. This says for Telligent.Caching, only pull revision 490 because that's the last known working version.

Tying it Back to Visual Studio

To circle back around to our Visual Studio projects, the various assemblies in the folders of the References folder is what our projects use for file references with regards to all the other non-third party assemblies we need. For example, if a project requires Telligent.Caching, it references Telligent.Caching.dll found in the References\Telligent.Caching folder, and if a project requires Telligent.Common, it references Telligent.Common.dll found in the References\Telligent.Common folder, and so on and so on.

Wrapping Up

I realize it might take a couple readthroughs of this post to fully grasp what's happening and how to use svn:externals, but once you get it you'll realize it's actually quite simple, and very effective. Feel free to ping me with questions and I'll try to help where I can.

Tagged as subversion , tortoisesvn , telligent , communityserver

Similar Posts

Christmas Vacation To-Do List

Dave — Thu, 18 Dec 2008 03:19:40 GMT

Like many people, this is my last work week of the year. After this Friday I am officially off work until Jan. 5, 2009 (but only for two days because then I'm off again the rest of that week for CodeMash, hehe), and I'm really looking forward to it. It's the first time since before I was a consultant that I've had the last two weeks of the year off, and it's even better this time because it coincides exactly with my kids' Christmas break from school.

But even though I'm officially off work doesn't mean I won't be busy with "work". You see, I've always looked forward to this time off because it allows me to catch up on things that I've been meaning to spend time with. So not only do I look forward to using my boys' as meatshields in Gears of War 2, but I've got a nice laundry list of things I plan on spending time with, such as:

ASP.NET MVC
jQuery
Fluent NHibernate
Ninject
Rhino Mocks
LINQ
Azure

I've dabbled in most of these over the past year, but nothing with real significance that I could consider myself an expert in, so it's time to get deeper with this stuff, and Christmas break is the perfect time to do it. To do this, I'm going to try to use them all together on a side project building a custom web site for our travel baseball organization. There's no better way to learn than by doing.

So what about you? Are you off for Christmas break? Do you have a similar to-do list?

Similar Posts

How to Link to Your Xbox Live Avatar

Dave — Sat, 13 Dec 2008 19:05:14 GMT

For everyone out there on Xbox Live, you've no doubt updated your Xbox 360 console to the New Xbox Experience (NXE) by now. I won't go into all the new features here, but I did want to point out something everyone might not be aware of yet: that you can add your Xbox Live avatar to any web site now.

For those unfamiliar (ahem, Nate), part of NXE is a complete revamp of the avatar system. Before NXE, all you had was the ability to pick from static images, either from the standard ones that come with the console or by buying others from the Xbox Live Marketplace. But with NXE you can build your own avatar, with different hairstyles, clothes, accessories, etc. The avatars are definitely a rip-off from the Mii system on the Wii console, but they look a lot better.

With the NXE launch, Microsoft also increased the integration of the Xbox Live web site with the Xbox Live platform itself, with one of those integration points being the avatars. If you check out the avatars page, you'll see a section that says "Share Your Avatar" that lists the links for you to add your avatar to your web site.

To save you the suspense, here's the format of your Xbox Live avatar:

http://avatar.xboxlive.com/avatar/YOUR-GAMERTAG-HERE/avatar-body.png

So to add your avatar to your blog or other web site, simply set your avatar URL as the source of an image tag, and you get something like this:

There is *some* resemblance of my avatar to me, but it's not nearly an exact match. The avatar I've seen that most resembles their actual look is Leon's. Heck, his even matches his personality, hat and all :-)

Tagged as gaming , xbox

Similar Posts

How to Suppress PowerShell Errors

Dave — Fri, 12 Dec 2008 15:49:00 GMT

If you've read my blog at all over the last couple weeks, it's pretty obvious that I've taken a liking to PowerShell; however, it's not been all sunshine and daisies. PowerShell definitely has a learning curve, causes a lot of trial-and-error, and is not without its frustrations.

One of those frustrations is how to suppress warnings and errors. For example, on my desktop is a folder named Temp, and in this folder I want to recursively delete all subfolders named Junk. To do so with PowerShell is quite simple and looks like this:

set-location C:\Users\Dave\Desktop\Temp
get-childitem -recurse -force |
  where {$_.name -eq "Junk"} |
    foreach ($_) {remove-item $_.fullname -recurse -force}

This works fine, but the output looks like this, even though the script did in fact recursively delete all subfolders named Junk:

Because the script did do its job properly, I guess it's not a huge deal, but it's very misleading. And it gets much worse because it will output that error message for each matching item, in this case for each Junk subfolder (just imagine a recursive delete on all .svn folders).

I put up with this behavior for awhile until I just couldn't take it anymore, knowing there *had* to be a way of suppressing these types of errors. It took some digging in to the get-help feature of PowerShell, but I finally found what I was looking for. If you type "get-help about_CommonParameters" at a PowerShell prompt, you'll see that one of the common parameters is ErrorAction, which is an enum of the following values: Continue (the default), Stop, SilentlyContinue, and Inquire.

So there it was, the answer I was looking for: SilentlyContinue. Now I can change the script to include an ErrorAction parameter with a SilentlyContinue value, like so:

set-location C:\Users\Dave\Desktop\Temp
get-childitem -recurse -force -erroraction silentlycontinue |
  where {$_.name -eq "Junk"} |
    foreach ($_) {remove-item $_.fullname -recurse -force}

And when I run the script again, here's the output:

You see those error messages? Me neither :-)

Of course, you don't always want to suppress PowerShell errors; you still have to be smart about where to do it. But for stuff like this, it makes perfect sense. And keep in mind ErrorAction is not limited to the get-childitem commandlet I've shown above; it's referred to as a "common parameter" for a reason :-)

Tagged as tools , powershell

Similar Posts

Modifying Web.config with PowerShell

Dave — Thu, 11 Dec 2008 13:21:00 GMT

For all you .NET-ers, you know how during your development cycle you set debug="true" in web.config, and then when you get ready to release your application you have to remember to switch it to be debug="false"? And how many times have you had to re-deploy your web.config all because you simply forgot to do that? Yea, me too, but I've figured out a way to automate this using PowerShell, and not only that, I've discovered how to do it in only five lines of code.

For completeness, here's a web.config file that contains only the <compilation> node with debug="true":

<configuration>
  <system.web>
    <compilation debug="true" />
  </system.web>
</configuration>

To change debug="true" to debug="false", I started down the path of using the typical XPath stuff to get the <compilation> node and its attributes. But in doing so, somewhere along the way I stumbled across an article (which I've since lost the link and now can't find) that showed a shortened, more terse way of making the change. You can see it in line 4 of this block of script:

   1: $webConfig = "C:\Inetpub\Wwwroot\MyApp\web.config"

   2: $doc = new-object System.Xml.XmlDocument

   3: $doc.Load($webConfig)

   4: $doc.get_DocumentElement()."system.web".compilation.debug = "false"

   5: $doc.Save($webConfig)

I assume the ability to do this has been around for quite awhile and I'm just now discovering it, but that makes things *so* much nicer than having to use XPath with XmlNodes and XmlAttributes. Using get_DocumentElement() to get the root node of the XML document and then simple dot notation to traverse the child nodes and attributes is a thing of beauty.

Just one word of caution: be sure to call the Save() method on the XML document object. I forgot to do that and spent an hour trying to figure out why my changes weren't being saved. Ouch is right ;-)

Tagged as tools , powershell

Similar Posts

Creating IIS Applications with PowerShell

Dave — Thu, 11 Dec 2008 01:39:22 GMT

To help automate our functional testing, I need to use PowerShell to create the IIS application required to run Community Server on our build server. After searching around, I found some articles that showed how to programmatically create a virtual directory, but what I need is a virtual directory that is actually an *application* in the eyes of IIS.

Kind of surprisingly, it took digging into the IIS SDK and this article to find what I was looking for. So after reading that and some minor trial-and-error, here's what I came up with:

   1: # Get parameters passed to the script   2: param($appName, $appPath)   3:     4: $path = [ADSI]"IIS://localhost/W3SVC/1/ROOT"   5: $app = $path.Create("IIsWebVirtualDir", $appName)   6: $app.AppCreate2(1)   7: $app.Put("AppFriendlyName", $appName)   8: $app.Put("Path", $appPath)   9: $app.Put("DefaultDoc", "Default.aspx")  10: $app.SetInfo()

A few notes:

Line 4: This is the IIS path to the Default Web Site on localhost.
Line 5: This creates the virtual directory.
Line 6: This is what turns the virtual directory into an application.
Line 10: This saves the changes in IIS.
This script works in both IIS6 and IIS7.
This script assumes the app doesn't already exist in IIS. If it does, an error is thrown.

If you save this script in the root of your C: drive and name it CreateIISApp.ps1, this is how you'd run it:

You could certainly enhance this script to check if the app already exists, or to pass in the server name and web site as parameters, but you get the general idea.

Tagged as tools , powershell

Similar Posts

Comments Now Powered by Disqus

Dave — Wed, 10 Dec 2008 02:16:08 GMT

One of the great things about having a blog is getting comments from people. Some posts get no comments, some get one or two, and then there are some that generate several comments, effectively turning those posts into discussions. But there are downsides with a basic blog commenting system, such as the lack of threaded replies and the inevitable comment spam.

So to enhance the commenting experience, and to get ScottW off my back since he's been nudging me about this for awhile now, I've swapped out the standard Graffiti commenting system in my blog theme for Disqus.

I won't regurgitate all the niceties of Disqus here, as Scott already did a good job of that (with steps to add it to Graffiti for those interested), but I'm looking forward to seeing if using Disqus really does enhance people's experience when leaving comments on my blog.

Feel free to comment away :-)

Similar Posts

Should Branch History Be Kept After a Merge?

Dave — Mon, 08 Dec 2008 03:30:04 GMT

As we've changed our development process to now work in feature teams and feature branches (much more on that in a later post), one of the things we're discussing is whether or not to keep the branch history once a branch has been merged back into trunk.

Initially, we thought of course we'd want to keep the branch history. Check-in history and revision comments are very important to us and that seemed like the obvious decision. However, we're now having second thoughts and are questioning whether or not the branch history even matters once it's merged into trunk.

Our thinking is that first and foremost, trunk rules all. Trunk is the mainline and should be kept sacred and *always* in a good working state; afterall, we ship trunk. A branch is a segment of work with specific functionality for a certain amount of time that, when completed and merged into trunk, goes away. Obviously history of trunk is extremely important, but should you really care about all the incremental changes that occurred in a branch before the merge occurred? We're beginning to think not.

So I wanted to ask the question and get feedback from you: should branch history be kept after a merge? Whether your answer is yes or no, I'd also like to see your reasoning in case we're missing something. Start/join the discussion by leaving your comments.

Similar Posts

Creating a SQL Server Database from PowerShell

Dave — Sat, 06 Dec 2008 13:59:27 GMT

My PowerShell scripting madness continues, with the need to automate the setup and teardown of a SQL Server database in prep for running automated functional tests. Here's what I came up with:

# Get the parameters passed to the script
Param($dbInstance, $dbName) 

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SqlServer.Smo")
$dbServer = new-object Microsoft.SqlServer.Management.Smo.Server ($dbInstance)
$db = new-object Microsoft.SqlServer.Management.Smo.Database 

# Loop thru the db list to find the one we need. If found, set the local
# vars to avoid errors when trying to delete the db from within the loop.
$found = "false"
foreach ($_ in $dbServer.Databases)
{
    if ($_.Name -eq $dbName)
    {
        $db = $_
        $found = "true"
    }
} 

# Now that we're out of the loop we can kill the db
if ($found -eq "true")
{
    "Deleting database $dbName..."
    $dbServer.KillAllProcesses($db.Name)
    $dbServer.KillDatabase($db.Name)
} 

"Creating database $dbName..."
$db = new-object Microsoft.SqlServer.Management.Smo.Database ($dbServer, $dbName)
$db.Create()

So to use this, let's say this is in a script named C:\CreateDatabase.ps1 and you want to create a database named MyDatabase on the default instance of the local SQL Server. This is what it would look like:

The -dbInstance and -dbName are named parameters passed to the script, which are grabbed in the first line of the script. PowerShell didn't like "(local)" passed in, so I had to escape the double-quotes to get it to be recognized properly, although you could certainly use the server name instead; I just wanted to show using "(local)" as an example. But other than that, all works as expected without any issues.

There's several other properties you can set on the database when creating it, such as the size, growth type, and file name, but if all you need are the defaults, the above script will take care of it.

Tagged as tools , powershell

Similar Posts

Tip: Use CC.NET Prebuild to Run Subversion Cleanup Before Building

Dave — Fri, 05 Dec 2008 15:23:00 GMT

If you've used TortoiseSVN for any length of time, you've no doubt encountered a situation where it tells you to run the Subversion "cleanup" command. This happens when TortoiseSVN needs to clear inconsistencies in your local copy, which means that under-the-covers it needs to re-execute log files within your .svn folders to get things back to a happy state. And usually when this happens, it's easy enough to simply right-click on the offending folder, go to TortoiseSVN, select Cleanup, and you're good to go.

But what if this happens on your build server while running your automated builds? It doesn't make much sense to log on to your build server every time this happens just to manually issue the cleanup command to get the build working again.

To solve this problem, add a <prebuild> element to all of your CC.NET config scripts that issues the cleanup command automatically. The existence of a <prebuild> element in CC.NET means that whatever tasks are inside it are guaranteed to run before anything else in the build script. For example, here's what the <prebuild> element looks like in our Community Server CC.NET build script:

<prebuild>
<exec>
    <executable>C:\Program Files\CollabNet Subversion\svn.exe</executable>
    <buildArgs>cleanup</buildArgs>
    <baseDirectory>D:\Builds\CommunityServer\Working\Trunk</baseDirectory>
</exec>
</prebuild>

Having a <prebuild> element in your CC.NET scripts ensures a smooth build each and every time without the need for ad-hoc manual intervention. And the less manual effort, the better.

Tagged as tools , subversion , cc-net , tortoisesvn

Similar Posts

TortoiseSVN Global Ignore Pattern vs. svn:ignore

Dave — Thu, 04 Dec 2008 13:57:54 GMT

When using a source control system, there are certain files and folders you normally want to exclude from source control. For instance, on projects developed with Visual Studio, you almost never want to check-in your bin and obj folders, nor should you ever check-in any .user or .suo files.

If you use the TortoiseSVN-Subversion combo, you have a couple ways to exclude files and folders from source control:

By setting the svn:ignore property on the relevant files and folders, or
By using the Global Ignore Pattern setting in TortoiseSVN

Using the svn:ignore Property

Let's look at the svn:ignore property first because I'm willing to bet that many people set this property without actually realizing it. With TortoiseSVN, it's really easy to exclude an item from Subversion source control by right-clicking on it, going to TortoiseSVN, and selecting "Add to ignore list".

That's simple enough, but you have to do this for each and every file/folder you wish to exclude, which can be tedious. But what's really happening is that TortoiseSVN is setting a svn:ignore property on the parent folder of the item being excluded, which will get committed for that folder on the Subversion server side during your next check-in.

For example, in my main Trunk folder I want to exclude a folder named Temp from source control, so I right-click it, go to TortoiseSVN, and select "Add to ignore list". To see the effect, I right-click on Trunk (the parent folder of Temp), go to TortoiseSVN, select Properties, and see this:

Before I added Temp to the ignore list, this box was empty, and now this change will get committed in Subversion and everyone else on my team will pick up the change the next time they get latest, which may or may not be the desired effect.

Using the TortoiseSVN Global Ignore Pattern

That's all well and good, but like I said, it can be tedious to do that for every item you wish to exclude from source control. Another way to accomplish the same thing is to use the Global Ignore Pattern in your TortoiseSVN settings. To do this, right-click on the root folder of your local repository, go to TortoiseSVN, and select Settings (notice I said Settings, not Properties). This is what you'll see:

It's here that you can enter any item you wish to ignore, and TortoiseSVN will save them in your local settings without ever adding svn:ignore properties to anything.

Tagged as tools , tortoisesvn , subversion

Similar Posts