Karl Fogel wrote:
> Karl Fogel <kfogel_at_red-bean.com> writes:
>> ...there are some big decisions we haven't made yet, about exactly
>> what goes into 1.5. That's going to need a separate thread (sorry),
>> and I'll post about it right after this. We really need to nail
>> down what's going in, whether we're shipping with an SQLite
>> dependency or not, etc.
>
> Okay, we just had a long IRC conversation about this (see transcript
> below). To summarize: we need to decide what's going into 1.5, and
> here's a list of open questions:
>
> 1. The #2897 (reflective merges) branch. Do we need to ship with
> it for 1.5, or should we punt and say this problem is too
> complex to put into the initial release of merge tracking. The
> latter way would mean adjusting user expectations accordingly,
> carefully documenting what 1.5 does and doesn't handle.
>
> This possibility is no slight on Kamesh, by the way: he's
> putting in a ton of work on the #2897 branch, and reflective
> merge handling should get folded in someday. The only question
> is whether we can afford more delay on 1.5 in particular.
>
> We do not currently have a clear answer about whether to try to
> incorporate that work into 1.5. The branch isn't getting the
> review it needs, because there's so much else going on. Should
> we try to make a decision now? (I won't try to hide the fact
> that I'm worried about merging a branch that big without
> substantial review; and I'm worried about delaying 1.5 more. On
> the other hand, if the feature is close to done and relatively
> stable, I don't want to turn it down, either.)
>
> This is the major outstanding question for 1.5. We need to
> settle it ASAP.
Speaking just from a feature point of view, I haven't looked at the code nor
have a sense how long it would be to stabilize the work, I'm of the mind to get
this into 1.5 now. 1.6 could be a long time coming to get reflective merges
into 1.6 (at least 9 months I would guess at the earliest), which will mean
people will still end up using svnmerge.py to handle this case. I'd like 1.5 to
make most of svnmerge.py obsolete. Not having reflective merges removes one of
the major points of merge-tracking.
Now after reading the IRC conversation, it appears that the amount of energy
going into #2897 isn't going to be enough for a faster 1.5 release, there's
nobody else really looking at the work. So if we want this feature, we should
merge it soon into trunk and deal with it in trunk.
Regards,
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-10 20:04:17 CET