I was asked a few times about recording a course, so I think that a few people would be happy to know that Glenn Block has posted a discussions that we had about a month ago.

You can find it here

Let us see how much of a furor that will cause :-)

The reasons that I don't like distributed source control systems have nothing to do with technical reasons, and everything to do with how they are used and promoted.

The main reason that I don't like them is that they encourage isolated work. I don't want anyone in my project to just go off and work on their own for a few weeks, then come back with a huge changeset that now needs to be merged. The way DVCS are promoted, this is a core scenarios, "no one have to see your mistakes".

I completely disagree. I want to see everyone's mistake, and I want them to see mine. There is little to learn from successes, and much to learn from failures. Far worse, I want to be able to peak into other people work, so I can give my input on it, even if it is just "wow, nice", or "yuck, sucks!"

The main advantage of DVCS is speed, trying to browse the repository when you have the entire thing on your HD is lightning fast, compared to doing the same with a remote repository. I tend to use SVK now, but I use it strictly as a local cache, and nothing more.

And that is why I don't like DVCS, I don't want people to work in isolation.

In about two weeks, I'll be speaking at DevTeach again. The last two times were enough to recharge me for months afterward, and I am looking forward to it.

I am giving several talks there.

Advance IoC - The use of advance means that I get to assume that I don't need to deal with intro stuff, so I am going to try to cram anything from generic specialization to aspect orientation to hierarchical containers and infrastructure ignorant applications. Success metric: people coming out of the talk saying "my head hurts".

OR/M += 2 - OR/M is no longer on the edge, it is a mainstream technology. That said, there isn't much knowledge out there how to take advantage of the non obvious advantages of using an OR/M. I am going to cover multi tenancy, adaptive and partial domain models, approaches for scaling, application design and architecture with OR/M and a bunch more.

DSL - This is a favorite topic of mine, this is actually an introductory talk, covering the range from "why do we even need this" to "how do we build them?"

Rapid (maintainable) web development with MonoRail - I gave that talk a few times already, but I think it is a time to give it a bit of a facelift, and try to do something a bit more impressive. So this is not going to be just "yet another intro to IoC", and it is going to dig deeper into more interesting scenarios.

I am also going to talk in a DotNetRocks panel, about the future of software development. The other parties in the panel are Scott (the Blogless) Bellware and Ted Newart.

Those are my talks, there are a lot of other good ones, and of course, the real reason that DevTeach is so much fun is the interactions with the people

Let me start by stating that you really don't want to do that. This is not something that you want to do, period.

Now that we are over that, I had the chance lately to go fairly deeply into SCM and how they are implemented from two fairly different perspectives. This is a randomly collected set of observations about SCM systems. As usual, the order is arbitrary, and no attempt was made to make any coherent idea out of this.

• It is all about the client. The client in an SCM system has significant responsibilities. It is in charge of reporting the client state, managing all the errors hat the user can cause, and shoulder a lot of the burden.
• It is all about the protocol. Anyone who designs a SCM system should be given a lousy DSL line with disconnects every 15 minutes. Oh, and they should also have to work on a plane a lot.
• On the wire, it is all so simple. It is really surprising to see how the SCM complexity is really just a lot of tiny, easy to handle, details.
• The devil is in the details, though.
• Complexities on the server side:
  • Space management - do you save the diff or the whole file?
  • If just the diff, how do you construct an arbitrary version
  • Keeping history around for branches and copies
  • Cheap copies
  
  
• Complexities on the client side:
  • Do you have one version on the client, per the working copy?
  • Do you have multiple versions, one per each file?
  • Handling inconsistencies between server version, working copy version and original version.
  
  
• What do you optimize for? Bandwidth? Roundtrips?
  • I know of one SCM product who is lousy optimizer for both
  
  
• Distributed SCM can be handled on top of centralized SCM.
• It is not hard at all, except for all the details.
• Don't write your own SCM.
• Trust matters, and you really don't want to be in the situation where you don't trust your SCM.
• Remember that SCM is temporal, you can go backward in time, and even sideway, to a branch.
• There are only three types of operations in SCM:
  • Generate a change set between two paths at two versions
  • Apply a diff to a path, generating a new version
  • Reporting (logs, mostly, and outputting various formats of a changeset)

Overall, it is very simple endeavor. It gets complex when you start talking beyond the wire protocol. As a simple example, how much does it cost you to branch? How much does it cost you to find out if there has been any changes to the working copy?
The other major issue is: How do you ensure that it is reliable?
Now, let me repeat myself, do not write your own source control!

I just finished talking with Apple Store's support. Due to a misunderstanding on my part, I ended up buying two iWorks licenses, instead of one. I called the store, got a human in less than a minute, explained the issue, waited a bit while she fixed things up so I get a refund for the extra license, done.

I wish it was all like this.

When a software project is started, there is a lot of new functionality to be written. Most of the time you are dealing with new code. After a while, if it is done right, you have a solid foundation that you can use to keep building the application.

Whenever I recognize this moment, it feels me with deep sense of satisfaction, this is how it should be. Rhino Mocks has reached that point some years ago, and I noticed that SvnBridge has crossed that point as well recently.

As telltales for this, I use the amount of effort it takes to build a new feature into the project. Take a look wt what was required to add svn sync support to SvnBridge, or the AAA support for Rhino Mocks.

I have just had to make a modification to SvnBridge because someone decided to checkin a change set that included 1,695 changes..

Even ignoring the issue of "your checkin broke my source control" mentality that I have now, this is bad from other perspective.

How do you review such a change? How do you even know what is going on there? In changes of this size, you aren't making a single change, you are making a lot of changes. Now you can't mix & match them either.

Prefer small checkins, they are easier to deal with.

Took a lot of work, and several months, but it is here:

Download Page

Krzysztof points out that Rhino Mocks has 26(!) methods to create various mocks.

I was very surprised to hear that, so I took a look, and he is right. The problem is how you think about those. Those 26 methods are only applicable when you count each overload as a separate method. Without counting the overloads, we have 10 methods. Then we have to consider options. In Rhino Mocks, you tend to have the following options: Create mock, create mock with remoting, create mock from multiple types.

That works to reduce the amount of options that we have down to about 4 different types of mocks that Rhino Mocks can generate. And you know what. Almost all the time, you don't need to use them. You only have to use DynamicMock and that is it.

Krzysztof suggestion would consolidate all the options to a far smaller surface area, but it would have several major issues:

• Break backward compatibility - I am wiling to do that, but not without due consideration.
• Break the documentation - See previous point.
• Force the user to deal with all the options explicitly - "In your face!" API design, from my perspective. That would lead people to create utility methods over it, which gets us right back to all the method options.

My DSL article has been published on InfoQ!

You can get it here