Branko Čibej <brane@xbc.nu> writes:
> In fact, I was hoping to provoke reactions to the tune of "let's show
> this lazy idiot who hasn't written a line of code in a month of Sundays
> what we're about!" Not a very orthodox approach in this forum, I'll
> admit -- hence the "rude and ridiculous" -- but it's the best I can do
> right now, and it did get some response in the right direction. :)
Oh, I'm sure you've been sitting around eating strawberries and cream
this whole time, yes :-).
> So for now I'll throw a few bones that I and/or others have been talking
> about for a while now:
>
> * The repository architecture (schema, semantics and back-end
> implementation) needs a complete overhaul. Refer to DannyB's and
> my and others' presentations at last year's Summit.
> * We do not have the resources to maintain two (or more!) repository
> back-ends or four (or more!) access methods.
> o Focus on /one/ repos backend -- the new one
> o Drop WebDAV as a protocol spoken by the client. We're not
> speaking real WebDAV anyway. If we need an HTTP-based access
> method (and I believe we do, for firewall/proxy reasons if
> no other), make it a RESTful variant of the svnserve
> protocol instead.
> o mod_dav_svn is useful for integration with non-Subversion
> clients (autocommit is useful) -- but it should be limited
> to that.
> * The working-copy architecture ... (shudder).
> * Divorce branches from copies. Branch, tag and copy are all
> conceptually different. Our simple "branch == copy" paradigm is
> indeed a low hurdle for people coming from SouceSafe or no VCS at
> all (wait, aren't those the same?) ... but is a total pain for
> project management. The number of hoops one has to jump through
> and "don't do that!" recommendations one has to follow to get and
> maintain a marginally sane repository structure is a serious hint.
> * Last but not least ... We should stop fiddling about with
> object-oriented code written in C. Our approach is only slightly
> better than the horror that is GObject. If we must stay with
> native-compiled libraries, let's do it in C++ ... in the last 7
> years, GCC 4 and Visual Studio 8 have arrived, so most of our
> original arguments for sticking with C no longer apply.
I think everyone agrees on these things as the long term plan. And
it's very tempting to say "Hey, why spend one minute writing any code
that's not directly leading to one of these things?"
But that's not the way a mature software project runs. We need to add
the 1.5 features on the architecture we've got, because users cannot
be expected to wait until the New World Order. The 1.5 development
process has made clear that we need some architectural improvements
(if I may indulge in understatement), but that doesn't mean we stop
developing 1.5 right now and spend months or more rewriting the
understructure.
At the summit, we did a good job of developing a technical consensus
about where to go. But we didn't come up with a plan of attack, a way
to get from here to there while simultaneously maintaining the current
Subversion. We're going to have to have that conversation after 1.5;
but in the meantime we can still make a very useful release based on
today's architecture. (FWIW, I don't think the current architecture
is holding us back quite as much as you do. It has its warts, but it
also deals with some things very well.)
Let's get 1.5 out the door, with merge-tracking, before we start
getting starry-eyed about 2.0. I'd love to be more idealistic about
architectural changes, but that's only possible when you don't have a
huge installed base and lots of compatibility guarantees to keep.
> "Ceterum censeo Carthaginem esse delendam."
Eventually, but... "Lord, give me chastity and continence, but *not yet*."
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 3 11:45:56 2007