Karl Fogel wrote:
> Branko Čibej <brane@xbc.nu> writes:
>
>> So ... we've made many wrong decisions, and I admit to making or
>> supporting quite a few of them. But I don't see any reason for
>> perpetuating them. So I suggest you (we?) all take a step back and
>> *seriously* start moving in the right direction [...]
>>
>
> Well, that's what we're trying to do. I understand that your mail is
> meant to be constructive, but a... little more specificity would be
> helpful :-).
>
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. :)
/In re/ more specificity: I think you'll agree that some aspects of the
Subversion architecture are seriously hindering the development of the
less trivial features. Yes, merge tracking is hard -- but we've been
actively helping to make it harder; and what I see as the holy grail of
Subverion-2.0, namely, true offline operation (including commits) and
cross-repository merging, is virtually impossible. (And note that I'm
not necessarily proposing a full DVCS!)
Whilst Subversion's view of the world may appeal to "the 80%" (thanks,
Ben!), I'm not very impressed by its usefulness for even
moderately-sized projects. I'd suspected this could be the case before,
but I've had this suspicion confirmed any number of times within the
last year or so -- much to my own detriment. Part of my frustration
certainly stems from the fact that I've not had time to do anything
about it.
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.
"Ceterum censeo Carthaginem esse delendam."
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 3 08:54:00 2007