James, when you compared configs/aliases, did you know about the ‘config-manager’ package? Its in debian, and install a command ‘cm’ which reads bazaar format configs or can be piped into it through standard in.
Config-manager supports configuration creation and introspection for tla, CVS and Subversion. I’m part way through a rewrite of config-manager into python. The python version supports check-out and update for baz and bzr.
fuzzyBSc – I really suggest not adding arbitrary methods to HTTP. Its standard practice for firewalls to take a deny unknown approach to handling unknown methods.
I think a more useful way of looking at HTTP methods and urls is from a message passing point of view:
GET = pass a query message to the object at the URL with parameters as per the URL.
POST = pass a mutating message to the object at the URL with parameters as per the URL/uploaded-message.
This gives you the as much flexability as changing the HTTP Method might, but makes the semantics of your request clear to all parties, which will aid debugging, reduce negative interactions with intercepting or mandatory proxies …
Stewart – dell hardware may suck … but what about samsung hardware with dell service ? Thats what my Dell X1 is, and I love it.
I went to the nsw annual CodeCon in the weekend, which was fantastic. While there we talked about everything from making an open source project flourish thru what makes a good sample rate converter – and how to prove it.
I had been planning to give a rant^Wtalk about how folk should extend unittest in python, versus how they are extending it, when someone I ended up putting my money where my mouth was. So KFish and I hammered out a minimalistic protocol for reporting test activity over a pipe, and I implemented subunit during the codecon. Peter Miller is planning on adding support for it to Aegis’s current test-suite support.
Luis: it is a concern. I wasn’t trying to say its not a concern – of course its something to think about. I’m saying that the net effect is easier returning of changes, rather than a net effect of easier-forked and not-merging code.
I completely agree that it is a social phenomenon that we’re dealing with. I don’t agree that the tools are the fundamental problem – way back when folk used patch to send everything around, forking and merging was common. These days its become a hidden thing with month long forks in a home dir while a feature is coded, and then finally committed, but I think the basic process has stayed the same: someone works on some code and collaborates via patch and diff with peers until its ready, when someone that has ‘commit access’ puts it in the mainline.
There seems to be a strong persistent meme that distributed VCS’s – Bazaar/Cogito/Montone et al – make it easier for people to fork projects and not return changes. I.e. to have ‘my libxml2’.
I think its important to note that people do this already, easily, by simply doing svn co svn://host/trunk. That is immediately a fork as soon as a change is made.
All a distributed VCS does is make it easier to return changes to the project.
Well, back at work aftersome much needed leave. Just before returning I attended the local Twisted Sprint, which was a great deal of fun. Amongst the things achieved are documentation improvements, a TDD variation of the finger example (which needs tidying up and human text to be put in the documentation), discussion of barriers to entry with Twisted, and last but not least, some refactoring of trial to fix a couple of annoying bugs, and prepare for making it not clash with unittest anymore.