Note:- I had an issue testing my SFTP connection when I configuring the deployment location and received the following error;
“Conection to ‘192.168.0.10’ failed. Invalid descendent file name “Accept:”.”
It turns out that I’d managed to somehow create a file called “Accept:” in my home folder in Ubuntu and the WebStorm IDE doesn’t appear to deal well with filenames that contain ‘:’, at least I think that is why. All I know is I deleted the file and was then able to connect without issue. Hope this helps someone as it took a while to figure out this morning in my pre-caffeinated fugue.
So I’ve been trying to get to grips with scripting for git to allow me to commit then deploy via FTP on Windows. I discovered git-ftp which looked promising but it was Linux flavoured, I followed the rabbit hole all the way to installing Cygwin and attempting to build it for Windows before realising I could just use PowerShell with Posh-Git and PSFTP (PowerShell FTP) instead. More to follow on that in the next post however though I’d share a few things I learnt about Cygwin first, no point in my learnings going to waste, this post is mostly a link dump.
Git-FTP can be found here and information regarding installing packages into Cygwin can be found at the source and there is a packpage manager, apt-cyg, that I never tried but looked useful.
A few issues I hit were that I sit behind a proxy at work so following this guide to configure Cygwin to have internet access. The guide works for http access and if you need https access, just used this command;
To access my existing git folder which sits in my Documents folder I mounted my C: drive in Cygwin then created a symbolic link;
mount c: /c
ln -s /c/Users/Username/Documents
This creates a folder named Documents in your home folder which maps to your Documents folder in your Windows user folder. I found this in a cheat sheet on a Stanford users site, very useful so my thanks to them.
All fun learning, more info on my PowerShell solution in the next post.
SSHFS is a file system that works over SSH, this allows for a secure connection to remote file systems and in my case will allow me to use the Windows based tools I’m familiar with against files on a remote Linux machine. I’m planning on getting to grips with Linux but it’s daft not to use the tools you know and this will likely prove very useful with the Raspberry Pi too.
The best method of using SSHFS with Windows I’ve found is outlined here, I’ve not tried with anything but a password yet but I’ve now mounted the disk of a user I have in a virtual Ubuntu server I’m running on my laptop. Seems to work a treat though not tried it over the network yet, with an upcoming move from Home Server to Ubuntu at home soon that will be likely be heavily tested.
After a two week hiatus from work and blogging, spent mostly at the ever excellent Reading Beer Festival, I’m back at work and doing something so simple I’ve utterly forgotten how to do it. As this blog started as a way for me to keep track of random things I learn over the years, it’s time to write this one down.
Here’s the issue; I’ve created an XML file and want to create a C# class library to work with it in code. It’s really easy once you remember how, through the use of xsd.exe.
Create xml file
Run “xsd.exe filename.xml” to create an XSD file
Run “xsd.exe /classes /language:CS filename.xsd” to generate a .CS file
One thing that always makes me chuckle is this line that is included at the top of each CS file;
“This code was generated by a tool.”
Today’s post relates to my experience installing Atlassian Stash on a headless Ubuntu box. My first attempt ended with me trying all sorts of nonsense which left the server messy as hell, including an accidental installation of Unity…
The trickiest part for me was the installation of Java as the version available via the package manager, OpenJDK, didn’t seem to play ball with Stash. No idea why but one of the helpful fellows from Atlassian, Stefan Saasen, pointed me in the right direction with this article which I’ve used as basis for the steps below, the browser plugin steps were omitted for obvious reasons.
First of all you need to grab the tar file for Java from here then get it onto your server, the easiest way I found was to use an FTP application in SSH file transfer mode. Then connect to the terminal and run through these commands;
Decompress the tar file noting that the file name will reflect the version you download and may differ from mine;
tar -xvf jdk-7u2-linux-x64.tar.gx
Move the JDK directory to /usr/lib;
sudo mkdir -p /usr/lib/jvm
sudo mv ./jdk18.104.22.168_17 /usr/lib/jvm/jdk1.7.0
Now run these lines, no idea why, explanation in the comments please!
sudo update-alternatives –install “/usr/bin/java” “java” “/usr/lib/jvm/jdk1.7.0/bin/java” 1
sudo update-alternatives –install “/usr/bin/javac” “javac” “/usr/lib/jvm/jdk1.7.0/bin/javac” 1
sudo update-alternatives –install “/usr/bin/javaws” “javaws” “/usr/lib/jvm/jdk1.7.0/bin/javaws” 1
Correct the permissions for the executables;
sudo chmod a+x /usr/bin/java
sudo chmod a+x /usr/bin/javac
sudo chmod a+x /usr/bin/javaws
If you are installing on a fresh server, that should be all you need for Java to work. If you’ve a few JVMs present on your machine, see the original article for steps to configure the default. For Stash, you can now follow the instructions here. One thing I found quite useful was the wget command that a colleague showed me, it makes downloading via the terminal quite easy, getting the Stash installer for example can be done like so;
For editing the setenv.sh file, and text files in general, I’ve found nano really useful. I’ve not ventured into the murky depths of the text editor holy war yet but this does the trick for now. I had to run the same chmod against the Stash home directory I created but after that I was good to go. Open a browser to the path listed in the console and use the wizard to continue setup.
As I’m implementing Git at work, I’ve decided to start using it at home too and for the site. As such I’ve dusted off an old account I’d forgotten I’d created and you’ll find me on github as jedibowler. The first of my projects to be posted is the code for the network enabled temperature/humidity logger from a few weeks back which can be found here.
If you’ve been following this series of articles, I’ve been attempting to migrate from Subversion to TFS 2012 over the last six months or so and have given up on the idea. It seems as though we are using a non-standard repository pattern which means the odds are stacked against us.
I’m not a newbie when it comes to troubleshooting TFS, I used to work in Microsoft Developer Support and it was my specialisation, but it shouldn’t be this hard to move from one platform to another. I know that the Subversion adapter is Alpha but I also attempted to use SVNtoTFS and the trial version of Timely Migration’s tool too without luck. I’m not sure if the way we’ve used Subversion makes it difficult to move history (update: likely yes) or if the tools just aren’t up to scratch with TFS 2012 but we need our version history and as we can’t get it into TFS, that’s that.
After a lot of effort, we’ve given up on migrating to TFS and instead we are going to use GIT and Stash, we’ve already licences for Jira and Bamboo too so will be investigating these as they are new products to me. We’ll be self hosting on Linux which should be an experience too and as I’m a Linux newbie I’ll be blogging my experience as I go in order to help other Windows veterans get to grips with things, as well as a reference for myself.
Update: Before leaving the company I had a play with TFS 2013 Preview and had success with the migration, I was made redundant before completing the process though would suggest people try this route.
We hit more problems, as per my last article that means another post! This post will detail the steps to troubleshoot a merge issue but the techniques I learned are good examples for generic troubleshooting of the TFS Integration Platform. Our issue;
A set of files aren’t being checked in after a merge in SVN.
Looking at the Subversion log I can see that the files should be checked in during a merge at a specific changeset. Looking at the TFSIP log you should see entries similar to “Processing ChangeGroup”, searching the solution for this string takes us to the MigrationEngine.cs file. I added an IF statement after the processing trace is added such that a break point can be hit when a certain changeset is reached;
Adding a breakpoint at line 347 means that you’ll be able to step into the code when a problematic changeset is reached and troubleshooting can begin.
During troubleshooting this issue I randomly hit the following error on build from the Interop.Subversion project, I resolved by cleaning only that project then rebuilding the solution;
error C1859: ‘Debug\Interop.Subversion.pch’ unexpected precompiled header error, simply rerunning the compiler might fix this problem D:\tfsip\IntegrationPlatform\Adapters\Subversion\Interop.Subversion\AprPool.cpp
I ended up hitting the same issue as mentioned in part 1 where a manual merge was required and for the life of me I couldn’t remember how I fixed it the first time around. Follows are my notes from each attempt;
“1039” issue – Manual rename of folder in TFS and check in;
Source = SVN version 1039
Target = TFS checkin 942
Undo pending change
Delete empty folder from folder B and checkin -> 942
Move from folder A to B and checkin -> 943
Get latest, undo pending change then open in Windows Explorer. Manually copy the files from source folder to target then within Source Explorer delete the source folder and add new items to target. Check in an cross fingers.
1039 -> 942
Rename B/WebSite to Website2 then checkin
Move A to B and check in
Manually map 1039 to 944
Hit start, map all conflicts to 944
Resolve Conflict in TE, Rename Server and check in
Map 1039 to 943 in TFS IP.
The simple step I should have taken, and wasn’t aware of, was to open Team Explorer and have a look at the list of pending changes. This helps a lot and was the troubleshooting step that worked around this issue. Migration continued
Around a thousand SVN revisions later we hit another issue, this time a runtime conflict; “Checkin failed for unknown reason”. I opened VS to check pending changes and found missing files, for some reason the Subversion adapter wasn’t getting a few thousand of the files for this revision from the repository. I manually got that revision from SVN and pasted into the TfsIpData folder and checked in to attempt a manual merge as before. I managed to check it in but when I kicked off the migration again it threw a few hundred conflicts.
It failed, and I’m sorry to say this is where the story ends as we are cutting our losses with the migration and moving to GIT and Stash. More on that in the next post.
After the last two TaW items have been less than successful, and as a last minute tie in to the No ‘Air Ambulance Challenge I’ve decided to upgrade one of my old projects. Rather than an RC car I’ve gone with a Syma S107G 3ch helicopter and standing in for the Netduino is an Arduino. I had a go at implementing the IR protocol in the .NET Micro Framework but it proved a little tricky. More information can be found in this post along with a video demo.