On Fri, Jan 30, 2009 at 06:36:44PM +0100, Lars Marowsky-Bree wrote: <snip>
Responding to this well-made and well-meaning critique, but also to the other posts on this thread.
Yes, having a powerful DVCS would be great, and it would fit the development of the build service well, also if you consider the existance of different instances of the build service that sources are transported forth and back between.
I nearly think that nowadays some design decisions would have been made in a different way. Regarding the existance of osc, which I am to be blamed for, I wasn't part of the build service team at the time, and needed to fill this gap by somehow interacting with the rest API, which was the only thing that existed back then. The build service was still closed source at the time, and only later has been open sourced, and the development process gradually opened up as well. Obviously, my own itch was to make use of this new system and not to rewrite it the system itself, and it was very easy to get something done with simple means (a simple script). A conscious design decision was to imitate a well-known VCS client as much as possible, because a different client would just have sucked. And something that may not be very obvious is that this imitation has hugely decreased the possible cost of invention of another client, because I never did really more than just do what they do, and see that it works. A large part of development effort would have flown into design, experiments, mistakes, and gradually getting where others have already gone, and it would have taken years. So the cost of developing osc may not be as much as you might think. On the other hand, there were two or three turning points where a little bigger effort needed to be put in, in order to make the thing scale and maintainable, error handling, getting some things right that had been omitted at the beginning. Also, the inescapable iChain proxy was a bad design choice, and I would have loved to change that from day one, but couldn't.
Speaking about currently lacking (and badly missed) features, it is obvious though that it's not trivial to implement them and get them right, so we are clearly at a point where it makes sense to reconsider the design choice of the employed VCS, and client.
I would encourage anyone trying this out - install the build service, and try to make it work with Git as source server. Don't just suggest such a change, but do something about it.
Regarding osc adjustment for such a change, it should be relatively easy to adapt to using a different backend, by scrapping a lot of code and replacing it with calls into the "real" VCS client. Or scrapping the code altogether, and using osc only for those functions and activities that are specific to the build service and not to be reflected in the VCS.
The more difficult part could be the "api" which all communication between osc and the backend passes through. It would be required to drastically change it as well, because it would either need to hand over other VCS's protocol then, or be thrown away altogether. Supposedly, the new "real" VCS would have its own, powerful, tried and tested api that doesn't need any further api in its front.
Thanks, Peter