[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] [MERGE REQUEST: lord] documentation and help enhanc

From: Aaron Bentley
Subject: Re: [Gnu-arch-users] [MERGE REQUEST: lord] documentation and help enhancements
Date: Thu, 06 May 2004 17:25:13 -0400
User-agent: Mozilla Thunderbird 0.5 (X11/20040309)

Tom Lord wrote:
> It seems sort of odd to use star-merge instead of apply-delta in this > context. The person who submits the merge request should have enough > data to use that instead.

I don't see merge packets as being end-to-end but rather as broadcast.

Oh. I don't get it. Do you see yourself pushing merge requests from tla--devo--1.3, for example? Because really, you don't hafta. I've already got auto-merging all rigged up.

No, the sender doesn't know enough to recommend an apply-delta because
while he can recommend a reference version he can't identify a
specific ancestor revision unless he knows the target revision.

Oh yeah. I was only considering the case where the merge was apply-delta $foo--patch-3 $foo--patch-5. But if the submitter has merged something from the target version in patch-4, it could get ugly. star-merge would be doing apply-delta $COMMON_ANCESTOR-REVISION $foo--patch-5, and.... ugh. Too many special cases.

A while ago I wanted to be able to specify the common ancestor REVISION to star-merge, but then realized that apply-delta would do the same job. Somehow I saw this as the same problem.

> I'd suggest considering the target revision advisory. That's the > revision that the merge is guaranteed to succeed for, so if the merger > really wants the merge, they can see what it would look like.

Advisory and optional, perhaps.  It would be a serious limitation if
the merge packet had to specify a guaranteed-success target revision.

I'm not so sure it would be bad to require a guarantee that the merge will succeed against something. Making sure the merge will work before submitting it seems like a best practice that I don't might requiring. And it's not like humans would have to work it.


Aaron Bentley
Director of Technology
Panometrics, Inc.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]