Re: Finalizing what's in 1.5

On Jan 10, 2008 3:04 PM, Blair Zajac <blair_at_orcaware.com> wrote:
>
> David Glasser wrote:
> > On Jan 10, 2008 2:18 PM, Ben Collins-Sussman <sussman_at_red-bean.com> wrote:
> >> On Jan 10, 2008 1:04 PM, Blair Zajac <blair_at_orcaware.com> wrote:
> >>
> >>> 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.
> >> That's an interesting question: is the branch so unstable (at the
> >> moment) that would make the trunk impossible to work on? If not,
> >> there's no reason for the branch to persist.
> >>
> >> My vote is the same always (which doesn't have much weight, since I'm
> >> not doing any work): Kamesh's branch is THE main use-case for
> >> merge-tracking and svnmerge.py. An svn 1.5 release without the
> >> ability to track and painlessly re-merge feature branches just isn't
> >> interesting to the general public.
> >
> > The reintegrate branch gives the ability to track and painlessly
> > re-merge feature branches.
> >
> > It may not give as much flexibility as the issue-2897 branch, but I'm
> > still not actually convinced that the issue-2897 version will actually
> > work as well.
>
> Why is that? How does issue-2897 differ from the reintegrate branch? What use
> cases are supported by one and not the other? I haven't been following these
> branches closely enough to know the differences between them.

It really depends what you mean "merge back from a feature branch"
should actually mean.

If you think it should mean "figure out the net difference between
trunk and the branch, as of the last time the branch was pulled from
the trunk, and apply that to trunk", then you want reintegrate.

If you think it should mean "find every single separate range of
changes done on the branch, and apply them one by one to the trunk in
order, possibly requiring resolving the same conflicts over and over",
you want current trunk code.

If you think it should mean "find every single separate range of
changes done on the branch, and apply them one by one to the trunk in
order, but before applying each range, see if there's actually some
merged revisions in there, in which case attempt to reapply the
changes done by the original merge in some temp files, and if this
happens to not cause conflicts, use that as a base for the diff that
you're applying to trunk, oh and you still probably need to resolve
the same conflicts over and over", you want issue-2897.

Now, I'm sure there are some cases where the issue-2897 algorithm is best.

But just like many SVK users gave up on using non "--lump" merges (due
to repeated conflict resolution, etc), I think that actually using the
issue-2897 version is going to be an exercise in unpredictability and
tedium, whereas the reintegrate version will either work correctly or
return an error saying (essentially) that you haven't been treating
the branch like a feature branch.

(There's no reason not to include both features, by the way; they're
orthogonal. I just don't want to include issue-2897 at all unless
several people have been convinced that it actually works well.)

--dave

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org