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!