SSMS (SQL Server Management Studio) modifies a table by simply dropping it, then re-creating it again with the new definition. However, when a table is replicated you’re not allowed to drop it (all kinds of nasty things could happen). Of course SSMS doesn’t tell you this is the problem, it just complains of something similar to this:

"Error validating the default for column 'rowguid'."

The only way (that I’ve found) round this, is to manually alter the table. Something I got taught at University, however I don’t use it much in practice so had to look it up. Luckily the syntax is nice and simple:

ALTER TABLE [table]
ADD [column] nvarchar(50) NOT NULL DEFAULT ('')
GO

This will add a column with the name ‘column’ to the table ‘table’ that is an nvarchar, with a max size of 50, that isn’t allowed to be NULL, and has a default value of an empty string.

Hopefully this will help someone, at the very least, it should give me somewhere to come back to if/when I run into this issue again.

Replication is great in theory, unfortunately, it is one of the most troublesome areas I’ve had to deal with.

Since I was the one who setup and researched SVN and Trac, I was fairly comfortable setting up a new repository or new Trac project, however it was quite daunting for any body else to step in and do, and even more daunting for me to try and explain the process to people.

Now that 2010 (twenty ten?) is upon us, it was decided we would move all active projects (those that we are still supporting) into SVN and create Trac projects.

We have about 50 applications that are still being supported, so even split among 4, I didn’t really want to have to go through the process of creating repositories and Trac projects for all of this, so I started looking into a way of scripting this. Since I’ve really not done much scripting before, it took me slightly longer than planned, but 2 work days (work was snowed off for 3 days this week) later and the script is ‘done’, so I thought I’d share it here, and share the difficulties I had. Maybe someone will find this useful.

If you just want the script, it’s available here.

The first thing the script does is ask for input from the user, for the project name (we decided to insist that Trac project folder names and SVN repository names were kept the same). It was also decided that we’d use underscores to seperate words in a project name.

I’ll go through the script, picking out the ‘interesting’ or parts that I struggled with.

set /P project_name=[Enter Project Name]:
set nice_project_name=%project_name:_= %
set project_name=%project_name: =_%


The /P on the set command allows you to set a variable to a line of input from the user.
For Trac, I wanted the project name to have spaces in, as it was nicer, so nice_project_name goes through the project_name variable, and removes the underscores (_) and replace them with a single space.
Then it does almost the opposite, to allow the user to enter the ‘nice’ project name instead of with underscores, I make sure all spaces are replaced with underscores.

mkdir %svn%%project_name%
svnadmin create %svn%%project_name%

Setting up the SVN repository couldn’t really be any easier. (If you’re having trouble with this bit, make sure that the svn bin directory is setup in your windows PATH variable).
Simply calling svnadmin create with the directory of the repository you want to create as the first argument and hey presto! a new repository.

Setting up Trac is almost as simple as setting up SVN was, the command you have to run is longer, and I had a bit of trouble with the project description as you’ll see in a minute.

mkdir %trac%%project_name%
call %trac-admin% %trac%%project_name% initenv "%nice_project_name%" sqlite:db/trac.db svn %svn%%project_name% --inherit=c:\trac_conf\trac.ini

If you’re using the nice_project_name variable, you need to make sure it’s surrounded with speech marks, since you’ll get complaints if you have spaces in the project name.

By passing the repository location to Trac, it’ll nicely link the 2 together for you, so you can see your source code from within trac, and (as you’ll see later) be able to close tickets from commits.

The only added thing there of any interest, is the --inherit=c:\trac_conf\trac.ini part, which allows us to use a single config file for trac. When given a file to inherit, Trac is smart enough to only include the parts that have changed in the project specific trac.ini file.

I then needed (well, I didn’t need, but really wanted) to include the description of the project. I could find no way to do this nicely, so I had to ‘hack’ a solution together.

set project_conf=%trac%%project_name%\conf\trac.ini
echo Project configuration file: %project_conf%
echo [project] >> %project_conf%
echo descr = %description% >> %project_conf%

This basically finds the project specific trac.ini file and bolts the description part of it on to the end. It doesn’t check to see if the description is already there (it shouldn’t be) and it’s a complete hack that I am not at all proud of. However, after spending several hours searching for a ‘nice’ solution, I gave in and this works.

Another thing that developers where I work didn’t seem to quite grasp, was the base folder structure to use in SVN. At the top-level, we wanted 3 folders: trunk, branches and doc. A fairly standard layout, but we ended up with all kinds of things, so I put this into the script as well.

set repoURL=file://localhost/Repositories/%project_name%
svn import c:\Repositories\.global\base %repoURL% -m "Create base folder structure."

This was another thing that took me longer than it should have done to figure out. I was trying to find a way to create a folder in the repository, without checking out first, I couldn’t. So the solution I settled on, was to create the folder structure somewhere on the server that was hosting svn, then just import that folder into the repository, thus creating our top-level folder structure.

The next thing I wanted to do, was be able to close Trac tickets from an SVN commit comment, so it was time to set up a post-commit hook in SVN. These go in the hooks folder of your repositiory.

Since this was again a step I didn’t want other developers to be concerned with, I scripted the creation of these hooks too.

set svn_post_commit_hook=%svn%%project_name%\hooks\post-commit.bat
echo call "%%~dp0post-commit-run.bat" %%* ^> %%1/hooks/post-commit.log 2^>^&1 >> %svn_post_commit_hook%

Because I wanted to be able to log the output, the first file post-commit.bat just calls the post-commit-run.bat file and outputs it to the log file in the same directory.

set svn_commit_hook=%svn%%project_name%\hooks\post-commit-run.bat
echo Project configuration file: %svn_commit_hook%
echo @echo off >> %svn_commit_hook%
echo "rem |%1 and %2 come from the post-commit.bat that runs this. They are the repository and the revision number." >> %svn_commit_hook%
echo set APPFOLDER=%project_name% >> %svn_commit_hook%
echo call C:\Repositories\.hooks\post-commit-run.bat %%1 %%2 %%APPFOLDER%% >> %svn_commit_hook%

Since all of the repositories will do the same thing, post-commit-run.bat just calls the global file, which looks something like this:

set REPOS="%1"
set REV="%2"
set TRAC_ENV="C:\trac\%3"
call C:\python25\python "c:\trac_conf\trac-post-commit-hook.py" -p "%TRAC_ENV%" -r "%REV%"

trac-post-commit-hook.py is the original found here on the Trac website.

If there’s an easier way to do any of this (especially the description bit of Trac) then please let me know.

I hope this post at least helps someone out, I had quite a lot of fun automating this, I might have to look into what else I can script to make my life easier.

I’ve put all the files (I think) needed for this to work (you will have to edit paths and such) into a zip file that you can download here.

I just finished watching the Google Wave video on YouTube, here.

Google have come along with a new technology called Wave. Watch the video to find out more about it (be warned, its a video from the Google I/O developer conference, so its a little techy). Basically they have stepped back from the way we currently communicate with each other (e-mail, IM, SMS) etc and, reinvented it. Its hard to explain, just watch the video (its long though).

There are times when I think Google are becoming the new Microsoft, the way they’re taking over everything and the way they buy new companies, however… Google keep proving me wrong, time and time again they surprise me.

I’ll try and summarise the features that I can remember (guess they’re the good ones):

• Live – All communication when using Wave is live, even the typing, so no more “Buddy is typing…”. Waves come and go in your inbox, even the search is live.
• Open Source – Woo! This means that other people can create their own Wave servers. Different wave servers can communicate with each other, using something called Foundation
• Collaboration – A wave is basically a smart document, or conversation. A smart docusation if you would. All the people involved with the Wave can edit the Wave at the same time and all the changes are displayed live on all the clients. Impressive
• Playback – When you are added to a Wave after it has already started, you will see all the edits/comments/conversations in the Wave already. Google have come up with a playback feature, which lets you see how the Wave was constructed. Another impressive feature.
• Extensions – Google demonstrated some pretty cool extensions, check them out in the video.
• Rosy – Live Translation! This was probably the most impressive feature of Wave, Google demonstrated two people conversing, one in French and another in English, Wave was translating what was written, in real time!

Overall I was very impressed with Google Wave, obviously as a developer I find this thing interesting anyway, but hopefully this will change the way people communicate world wide. For the better. Open protocols, Open source.

Google have impressed me today.