David Glasser wrote:
> 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.
So reintegrate is the mirror of rebasing a branch then.
> 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.
Thanks for clarifying them.
> 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.
What will cause a branch to not be usable by the reintegrate feature? If you
only do merges between the branch and trunk, will you be fine? If you merge in
changes from a location that is not the trunk, will that break reintegrate?
Hopefully if reintegrate fails and warns the user, it tells the user what they
need to do to do the merge.
> (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.)
Reading your description makes it sound like 2897 will require us to test the
feature, which sounds like you want to test it without merging it back into
trunk. I guess we can always pull it out of trunk if need be.
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-12 23:17:05 CET