"Subversion 1.5, Technology Preview"

First, let me say that I mean no offense to those who have
actually written these features. While they were doing the heavy
lifting, I played my usual role of criticizing from the side,
committing bug fixes here and there.

That said, let's review the new features in 1.5.x:

# Merge Tracking

  We have a lot of code to manipulate the mergeinfo model. But
  use cases as simple as "a feature branch which you sync up
  every so often and then merge back" don't really work yet
  (reintegrate is supposed to help here, but see the
  reintegrate/renames thread). Certainly, nobody has had any
  real experience using it yet.

# Sparse checkouts

  This works pretty well (though it interacts subtly with merge
  tracking, and specifically is incompatible with reintegrate),
  but we have neither API nor UI for decreasing the depth of a
  working copy.

# Copy/move-related improvements

  svn mv *.c src/ works.
  svn mkdir --parents a/b works.

  The new feature to handle the case where I have foo.c modified
  and update to a revision where you've moved it kind of works,
  in at least one case, right?

# Interactive conflict resolution

  Kinda works. The accept-mine and accept-theirs actions are, as
  repeatedly discussed, not even close to ideal. The diff action
  diffs shows the wrong diff, and blows out your scrollback.

# WebDAV transparent write-through proxy

  I have no idea; I guess it works.

# Cyrus SASL support for ra_svn and svnserve

  Vlad got it to work, and I got it to work. But Vlad wrote it,
  and I had to hack on it first. I'm not confident it works with
  other mechanisms without hacking, either.

# Changelist support

  Kinda works, if you completely understand the quirky way it's
  implemented. Yes, a large part of this is our working copy
  library. Let's rewrite it for 1.7 :).

# Relative and peg URLs in svn:externals

  Woohoo? This one's actually pretty comical, because externals
  has been exactly the kind of half-baked feature I'm lamenting
  here, since before 1.0. Some of us tried to get the feature
  removed before then. It's still half-baked in 1.5.x.

# FSFS sharding

  Works!

# Easier to try out experimental ra_serf DAV access module

  Still doesn't seem to be quite there. There were even major
  disagreements over whether it's violating the editor interface.
  Doesn't work with the Python bindings (I know I know, I never
  posted a reproduction recipe; making our binding test suite
  ra-independent is still on my stack).

So, most of these are unfinished, and not necessarily what a user
wants or expects (especially merge-tracking and changelists). We
may even have to change the UI incompatibly when (if; see externals)
we finish them.

Also, these features interact with each other in very interesting
ways. None of them are very well tested at all. We still aren't
even eating our own merge-tracking dogfood. 1.5.x includes a lot
of new code, most of it complex. This is going to be our
buggiest release in a long time, possibly ever.

Doom and gloom => let's spend another year slogging through it
with no release in sight? No.

We have precedent in the free software world for "technology
preview" releases. FreeBSD has done it, if no one else. I think
Apache did, too, at the beginning of the 2.x series.

I propose that we take 1.5.x through the full release process,
just as we did with prior releases, and release it to the world,
and lifting our discouragement of packaging. But, let's:

- advertise it as a technology preview

- be explicit and honest about the status of the new features,
  and our plans for 1.6[1]

- declare up-front that we may break compatibility *with the new
  features* in unprecedented ways in 1.6 (but maintain ABI
  compatibility?)

Some will say that this will lessen our standing among free
version control systems even more. That is unavoidable; we are
where we are. I think *not* going the technology preview route
will damage us even more.

[1] Yeah, we really need to start thinking about that...

-- 
Eric Gillespie <*> epg_at_pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org