On Wed, Feb 27, 2008 at 7:51 PM, Eric Gillespie <epg_at_pretzelnet.org> wrote:
> 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.
I do not agree with your conclusions, but I do not take any offense.
It would be really easy to look at Subversion up to 1.4.6 with a
highly critical eye and compose the same email. There is plenty of
evidence that says despite the shortcomings of various features, SVN
has been pretty damn successful so far. If I had been a committer
prior to 1.0, I would have had a very hard time supporting the lack of
any real support for renames (even when 1.5 ships). For me, and lots
of Java developers, that is a critical feature that SVN misses the
boat on. In retrospect, even though I still really want this feature
to work better I think the committers made the right call in shipping
SVN when they did. If you do not ship, you do not help anyone.
Others would certainly lament the merge capabilities prior to 1.5 and
wonder how the product ever shipped. For others, it would be
externals (lack of true CVS modules replacement). Please keep all
this in mind. I do not think your proposal is the right direction and
I do think you are being overly critical of the features.
> 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.
There is no arguing that we do not really know how this feature will
hold up in real world usage. That being said, we also do not know
that it doesn't or whether the next round of changes we need to make
will be "easy" or hard. I think pre-1.5 merge in SVN is decent (it
has always served me well). I think 1.5 improves it.
> # 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.
I do not see the lack of this UI as a killer. That it would not be
included has been said since last spring. There has been plenty of
time to raise it as a must-have. (I know some people have raised the
issue, just not forcefully, and certainly not to the point of
contributing code).
> # 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?
The copy/move improvements are big. For example, you can now rename
something multiple times before commit. This is a really huge
improvement for refactoring tools. The syntax support for doing
multiples is nice as is --parents. The stuff that Ben contributed was
never really in the plan for 1.5 anyway. I think it works for pure
copies, and can possibly work for moves if the ordering is right. It
would be a killer improvement if it always worked, but at least he
lays the foundation. We could always remove the feature before
launch. I think cmpilato has suggested that several times.
> # 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.
FWIW, this feature works perfectly for GUI tools. I have zero
complaints as an API consumer.
> # WebDAV transparent write-through proxy
>
> I have no idea; I guess it works.
Same here.
> # 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.
Same here. I am struggling to tell my release engineering team at
CollabNet what they are supposed to build and include.
> # 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 :).
This is another one that just kind of came out of nowhere (*cough*,
*Google*, *cough*). If it does not do what you guys want, then why
did you add it? It seems like a lot of people took "your" word for it
that this was going to be useful. I know there has been some question
on syntax/semantics, but it seems like it is right now. My biggest
concern is that users tend to be surprised by two aspects of this. 1)
That they are not somehow persisted in the repository after commit.
2) That it does not work on file hunks. "I" understand this, and I
think users do after it is explained. But that has been what I see.
> # 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.
I do not think this one is fair. Externals has several known issues
that either are a problem or not for different people. This change
does address one class of those problems. The feature is better for
many people now. Because it still has other problems, does not make
1.5 a bad release.
> # 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).
No comments.
> 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.
We never have been eating our dog food at this point in a release
cycle. At least since 1.0 came out. This is pointless. We barely
even use merge in this project. How many SVN developers were that
troubled by the 1.4 merge code when doing SVN development? Certainly
not enough to contribute to the merge tracking feature! I think we
know 1.5 is going to make it better for our usage. I think we also
know that we are unlikely to uncover many problems in our own usage.
What we need is to get the release process moving so real users can
try the features.
Again, I do not think things are that bad, and I do not think your
proposal is the way for us to go. I think SVN 1.5 will be better than
1.4 and previous releases. In some cases, substantially better.
Because some features are still not as good as we would like is not a
reason to downplay the release itself. Like I said in the beginning,
how could anyone look a user in the eye and say that they think our
support for renames is good enough? Yet we have shipped many
releases, including this upcoming one, without changing it and we
still have experience exponential growth. I think 1.5 will be our
best release yet.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-28 02:36:02 CET