We have released IronRuby 0.9.2, the latest release on the way to the 1.0!! The thing I’m most excited of in this release is the presence of a MSI installer file. I got that installer going, and I’m dang proud of it ;) So, install, enjoy and please tell us what is missing so that we can feel proud of a complete 1.0 release.
Well, things have changed.
As you may have noticed, the blog theme has changed, old comments are gone and you got a slew of items in your RSS feed.
IronRuby Testing and Development got deleted by my host due to a billing miscommunication, and I didn’t find out about it until it was too late. Sorry about that. I’ve re-uploaded the posts I have, but there isn’t anything I can do about the rest.
On the plus side, I’ve posted a new post in the Git-TFS series and I want to do a Beer of the Week posting this weekend. I’m trying to get back in the rhythm of weekly posts.
Thanks for sticking with me through the pause.
JD
So, I want to start this with another apology. I didn’t mean to start this series then drop off the face of the earth, and I didn’t mean to state that I would finish this series, and then disappear again.
OK, since that’s out of the way, lets get to the real reason you’re here:
So if you read the table of contents, you know that the 3rd article in this series was supposed to be Decision. Well, I told you what the decision was last week, so I decided to skip that article.
Instead, these last few articles will go into detail about how we have the wrapped TFS repository implemented. It’s fairly simple to be honest, but I’d like to delve in. Today we’ll talk about how it’s setup, and soon I’ll share a PowerShell V2 module that implements this setup.
The basic manual setup is as follows. Map a TFS workspace to the structure you want the Git repository to be in. I highly recommend using making this opt-in. The folder’s that you want should be active, and in the cases where you only want a part of a folder, activate only those parts of the file that you want. Avoid cloaking folders since that usually means you are opting for the entire folder and then opting-out of folders that you don’t want. The danger here is that if someone adds a folder that shouldn’t go out (for example, maybe it contains your signing key), opting in means that folder is left alone, and won’t go out. Opting out means that the new folder will suddenly appear in your Git repo.
Once you have your workspace setup you need to go one folder beneath your mapping. So for IronRuby, the mapping is all underneath Merlin and NDP. Merlin holds the languages, non-2010 DLR, and tests, NDP holds the parts of the DLR that are going into VS2010. On my primary computer, the path to those folders is C:\vsl\rubysync\{Merlin,NDP}. Therefore, I initialized the Git repo in C:\vsl\rubysync. If you already have a Git repository, then you need to clone that Git repo somewhere else on your computer (in my script, it gets cloned in $env:TEMP). After you clone your repo, copy the .git folder into the proper root folder (C:\vsl\rubsync in IronRuby’s case). Finally, you need to synchronize your repositories. Do a tf get /overwrite to get the TFS side up to date, and then, from the root of the repo (where you copied the .git folder) do a git add . followed by a git commit -a -m ‘your message here’. This makes sure that all adds and deletes are automatically picked up. You can feel free to do it manually, but in the current implementation, that isn't worth it for IronRuby. Follow all of this with a git push, and you should be good to go (you may need to setup origin if you initialized a new repo).
So there you go, the basic setup. I highly recommend forking the remote repo for your personal work so that only the Git-TFS bridge repo is pushing to that repo. To update the git repo, just repeat the git add ., git commit -a –m ‘message’, git push series of commands. The reverse is a little more complex, and I’ll talk about that next time, hopefully with some scripts to share.
Big week for MS. Be sure to check out all of the great launches from the following teams:
And of course:
First I want to say sorry I've been so quiet lately. I know many of you were following the Git-TFS series, and I’m sure my pause was annoying to say the least. I’ll be hitting it up again this week, and I’ll have scripts to share with ya’ll :)
JD
Antionio Cangiano has reported on the state of IronRuby on Windows, where IronRuby is showing the fruits of Tomas’ labor:
IronRuby went from being much slower than Ruby MRI to considerably faster across nearly all the tests. That’s major progress for sure, and the team behind the project deserves mad props for it.
I’m happy to see these numbers (and happy that they confirm my personal benchmark runs), and looking forward to our upcoming 1.0!
BTW: For those of you who are waiting, expect Beer of the Week tonight, and the next part in the Git-TFS series soon. I’m trying to clean up some scripts to share with ya’ll.
I told you that I would find a beer that you can easily find outside of Seattle!
Today I bring you Blue Moon’s Honey Moon Summer Ale. From the bottle:
Capture the summer with Honey Moon Summer Ale, a two-time gold medal winner. It’s a classic summer ale made even better with real clover honey. Then we add our trademark twist: fresh orange peel and the perfect blend of pale and white wheat malts. Perfect for as hot summer day.
5.2% Alc by Vol. Blue Moon’s beers are my old standby. I always enjoy them and they are always refreshing for me. The Honey Moon is a rather clear ale, but it’s full of flavor. It’s sweet, but not so sweet that it overwhelms. It also has a clear taste that just refreshes and relaxes. I’ll admit that it’s a simple beer, but perhaps that’s why I like it. It isn’t a beer that will clash with anything I have with it.
We interrupt our regularly scheduled Git-TFS series to bring you this exciting news:
IronRuby 0.9 has been released!
Release Notes
It’s been a long ride since IronRuby was announced at MIX ‘07, but now all eyes are focused on getting it to 1.0. The past couple of versions have made vast compatibility and performance improvements, and 0.9 marks the last set of major features that will be added to IronRuby. From now on, all IronRuby languages will be primarily focused on bug fixing and anything else the community deems necessary to call IronRuby a 1.0 release. These improvements be delivered as point-point releases (0.9.1, 0.9.2, etc) until you decide it is ready to call 1.0.
Though IronRuby is breaking away from it’s conference-driven development schedule, this release comes only a week after OSCON 2009 where I talked about using IronRuby with Mono and Moonlight, and scripting open source apps.What's in the Release?
Library performance was a big focus for this release; basically going though the Ruby Benchmark suite and making sure any obvious slowness was fixed. As I said in my previous post about OSCON, IronRuby is approximately 2x faster than MRI when running the benchmark suite, but in the near future a complete evaluation of IronRuby’s performance will be done and published on the website.
On the compatibility front, the Win32OLE Ruby library is now available in IronRuby. This builds on top of IronRuby’s existing COM interop from version 0.5, letting you script any Windows component/application that exposes a COM interface. Though it hasn’t been fully tested yet, this will make things like Watir work on IronRuby.
Lastly, there have been interop improvements with .NET, most notably making Generic types more friendly to all the crazy things Ruby can do to them, and also with other DLR languages, making it really easy to call IronPython from IronRuby.
For more detailed information, please see the CHANGELOG (which includes all commit messages for the release ... not just "syncing to head of tfs").
You can also try IronRuby in the browser out on the CodePlex site.
Enjoy!
So last week I reviewed Snoqualmie Falls Steam Train Porter, so I bet you thought I’d be new and exciting this week and do something completely different.
You thought wrong :)
This week I bring you Snoqualmie Falls PGA (Perfectly Great Amber) Ale. Full disclaimer: I’m not a big fan of amber ales.
From the bottle:
PGA is a marvelous session beer with just the right amount of Two-row Pale, Munich, Crystal and Aromatic malts. Finish with a touch of sweetness, this ale is perfect for the 19th hole, while watching the game, or just relaxing with friends.
Alc by Volume is 4.0%. This ale definitely has the malty, hoppy taste to it. It is slightly on the bitter side but, as the bottle says, it has a sweet finish. The aroma is a classic beer aroma, little bit of sweet, little bit of bitter. On the downside, one of my first, and strongest, thoughts about it was it’s bitterness. I also mentally compared it to mass-produced American beers (which may not be too bad since, I believe, many of them are amber ales).
Overall, I’m neutral on this beer. It’s not my favorite, but it’s still good. Give it a try and let me know what you think.
Next week, I’ll try to find something that you can find a little more readily outside of Seattle! Also, if you want to recommend (or send) a beer to me, leave a comment and I’ll keep an eye out for it. Enjoy!
For the second part of the series, I’d like to discuss some of the options we thought of and why we said no.
In addition to our source control systems, we have a Continuous Integration server that runs before checkin. We use TFS’s shelveset feature to submit items to the CI server, then it does a tf checkin when it verifies the shelveset.
Another consideration, is that the TFS instance we use is shared by all of the Visual Studio team. Because of this, we can’t rely on every checkin to be one of ours, and we also have to expect that some checkin’s to our files should not have all information about them exposed to the world (commit messages about pre-release features, for example). Due to this server, we wanted to make our solution ensures that pushes to the primary IronRuby Git account passed these tests.
We considered quite a few options for this:
git-tfs adapter similar to git-svn Don’t do it, go with only Git with sync points
We considered moving the majority of IronRuby’s development off of TFS and only syncing up with the DLR and IronPython at specified intervals. This would have been nice as it would have gotten everyone working out of the same repository and it would have eliminated these entire problems. However, the DLR is evolving too quickly to allow this, and we need to change it too often.
Have one checkin system to checkin to Git and one to checkin to TFS
This would have required massive changes to the checkin system in order to make it understand Git, and it also would have required an internal staging server to allow us to push to. It solved the problem of keeping the source tree passing tests, but it didn’t solve the problem of keeping the two systems in sync. We did consider trying to have the checkin server also push to the external Github account. However, this would have been more changes and would have made an external website able to block our internal systems. Some people also had security concerns with having the CI server automatically pull in external code.
Continue with the transform route that the SVN repo used
When IronRuby used Rubyforge’s SVN repositories, we also used a different source layout. We had scripts that transformed the two repositories to allow syncing these layouts. While this worked, it was error prone. There were heavy maintenance costs to keep the transforms working. There were also numerous cases of overwriting changes on one side or the other of the transform. We decided early on that whatever we did, transforms were out.
Write a git-tfs adapter similar to git-svn
This was tempting, and it is something I had considered since I started at Microsoft (since I love Git, and I’m not as wild about TFS). We chose not to because we didn’t really have the resources to write and maintain it.
Use file copying to transfer between TFS and Git, branches to handle merging the files
The idea with this one was to have 2 repositories: one Git and one TFS. To sync repositories, we would xcopy files from one to the other, then run a git commit or tfpt online to get changes into the repository. Then, to merge them in correctly, we would use a branch to allow the source control system to do the merge. We actually started on this path before we went onto the one we used.
Wrap the TFS repository in a Git repository
Jimmy Schementi is the one that pointed out that there was no reason to have two separate repositories on the system. Since TFS doesn’t store it’s information in it’s enlistment and it doesn’t use extra folders (like SVN), you can just add the .git folder at the root of the “git repository”. Git will take care of itself and track the files, and if you do regular tf get’s, TFS will also stay in good shape. The rest of this series will go into details about this technique, and it will also talk about the scripts we use.
