Exensability: Ask, and you shall recieve
time to read 5 min | 806 words

Bil Simser has a few things to comment about me and Roy's discussion about TFS vs. the OSS stack:

Yes, other packages out there are extensible by nature (Subversion for example) but require coding, architectural changes, hooking into events, all of which are nice but systems like this were not designed for it.

That depends on what you want, but usually coding is not involved, scripting usually does. Arhcitectural changes, etc, are usually not involved.

Was subversion really designed at the start to be extensible so I could maybe have my storage be in a relational database rather than the file system?

I am not familiar with SVN's internals, but I would answer yes, it already has two storage providers, adding a third should be possible. Let me turn that question around for a moment, can I extend TFS to use Oracle as the backend storage?

Could I crack open subversion to support a way to link checkins to an external feature list? Sure. Why would I when TFS has this already.

And since Subversion has this already, the point is moot at any rate.

And finally, the piece that caused me to post it here:

As for modifying open source systems to do your bidding, you enter into a fork scenario. Unless the system supports a plug-in pattern and you can just add a new assembly (like say oh the TFS policy sub-system) I really can't do much with a tool even if I have the source code, unless I want to run the risk of being in a maintenance nightmare from Hell scenario. Do I really want to do diffs of new relases of NUnit with my own code to support new extensions.

Forking isn't nice for you, and I would usually recommend against it. But the point is, most OSS projects already have an extension model. NUnit certainly does, Rhino Mocks does, Subversion does, NHibernate has them all over the place, Castle Windsor is a big (and beautiful) extensibility model all in itself, log4net lets you plug in at any point in the pipeline, etc.

In fact, that is one of the reasons that I like OSS, because so often they have this really nice model of safely extending the functionality. Bil mentioned extending TFS to include a "steps to reproduce" field, here is the same for Trac:

[ticket-custom]
repro = textarea
repro.label = Steps to repreduce
repro.cols = 60
repro.rows = 30

Very simple to extend, and if I wanted to add logic as well, that is simple to do as well.

And while it might have deficiencies in various places I can plug in new features or introduce entirely new concepts to the repository so that I can make it match whatever business process I use.

TFS makes me wait for it, that doesn't mesh with the way I do business. Please instruct me at the values I should put in the "MakeIsFast.config" file.

Is the source control system in Team Foundation Server extensible or replaceable? No, but I'm willing to live with a few problems while we get to version 3.0.

I think that you under estimate just how critical this deficiency is to me. It makes me snap out of the zone. It makes me aware of the tool, and not in a good way. If a tool get in my way I would either improve it or throw it.

Tweet Share Share 3 comments
Tags: