[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Reality check

From: Branko Čibej <brane_at_xbc.nu>
Date: 2007-12-03 08:53:30 CET

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.