On Nov 30, 2007 6:15 PM, Karl Fogel <kfogel@red-bean.com> wrote:
> > Yes, this is what the plan has been for quite a while now.
>
> I'm glad to hear you say this :-). But, others seem to think
> differently, so it's important we hear from them too...
I'm not sure what to say, guys. So much drama in such a small period
of time. Eesh.
I know it's ridiculous (and rude) for a bunch of people who haven't
been paying attention to merge-tracking details show up at the last
minute and challenge a bunch of decisions that were made months ago...
it's certainly frustrating for those who *have* been killing
themselves on merge-tracking. So I apologize. I know it's unfair, I
know I should have been paying more attention. However, I can't go
back in time and speak up when I should have, so all I can do is speak
up now. I was aware of the func-spec at the beginning, I wasn't aware
we had started deferring big parts of it.
From where I sit, it looks like the people who have been heads-down on
merge-tracking implementation {dlr, kamesh, cmpilato, kfogel} decided
a while back to defer a difficult portion of reflective merges to 1.6.
But I also feel that these same people have lost perspective; that
they're deferring something at the very core of merge-tracking.
Mark, Jack, Danny, Blair and I all think that losing a user's
conflict-resolving changes during a merge is not a small thing. It
effectively ruins the main use-case. It leaves us with a
partially-implemented core feature whose boundaries aren't clear to
the user ("do I need to specify a revision now? How about later?
Hey, didn't I already resolve these conflicts?"). It would actually
embarrass me to try and document this in the svnbook... it's nearly as
confusing as the status quo.
What worries me even more is that people like Folker are suggesting
that our current design can't *ever* handle this case. I've not yet
evaluated his long mail, but I think it would be foolish to put off
issue 2897 to 1.6 when we don't even know if it *can* be done. We
need to have extreme confidence in our design to defer something this
complicated, not wave our hands and say that we'll figure it out
later.
I know that there's huge pressure to release 1.5 -- collabnetters are
burnt out from working on it. Other devs are dying to see their
smaller features released already. Collabnet has customers banging
down the door for it. But releasing a half-implemented feature (with
no certainty that it even can be finished correctly!) is FAR worse
than going back to the drawing board and spending another six months
getting the design right. I hope that's not what it takes, but we
can't let all these pressures divert us from our original goals.
Frankly, if we release 1.5 and can't handle feature branches
correctly, I don't think we should even advertise merge-tracking. We
would change our marketing to focus on the myriad of other smaller 1.5
features, and simply say that a "few merge improvements" were made,
and that real merge-tracking is coming in 1.6.
I apologize for making such a stink when I'm not the person who's
about to hunker down and write the code... it goes against the whole
meritocracy concept. But I'm advocating what I think is best for the
project, even if that means admitting that (to some degree) this
project has encountered a major failure. Failures aren't things to be
in denial about -- they're things you embrace and learn from.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 1 03:03:54 2007