monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] automate sync display branches?


From: Stephen Leake
Subject: Re: [Monotone-devel] automate sync display branches?
Date: Tue, 21 Sep 2010 18:05:39 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (windows-nt)

Timothy Brownawell <address@hidden> writes:

> On 09/20/2010 02:05 AM, Stephen Leake wrote:
>> One request: you committed one revision that is both a propagate, and
>> has other changes:
>>
>>     8434d5524dde039f70c7ff347b5de32cf7b9043b
>>     2010-09-19T21:03:25  Timothy Brownawell<address@hidden>
>>       Merge in changes and apply move of {keys,revs,certs}_{in,out} out of
>>       netsync_connection_info into their own separate container.
>>
>> That makes it difficult to review, since there are lots of changes I've
>> already reviewed. Please do this in two commits.
>>
>> Just out of curiosity, how did you do the "merge in changes"? This
>> doesn't look like you used 'mtn propagate'. Maybe you did
>> 'merge_into_workspace'?
>
> Yes, merge_into_workspace and then the necessary changes to get it to
> compile with the counters being moved. 

Ok.

> I'd thought that it belonged as part of the merge, since it was
> basically taking a language-token-rename from one side and making sure
> it was applied to the result properly in ways that our
> non-language-aware merger can't handle correctly (ie, with a
> Sufficiently Intelligent merge algorithm it would have been part of
> the merge automatically). 

I see your point

> But on the other hand I guess it *does* interfere with 'diff'...

Yes, at that point I wanted to focus on what effects your changes had on
my code; I had already seen all of your changes (to see if you are
Sufficiently Intelligent as a merger :).

Given our current tools, I think it's better to just propagate,
resolving only merge conflicts, and then fix the language/compiler
conflicts in a second commit.

But there should be a way to review what I want given your work flow.
For example, in reviewing a propagate revision, I can show the conflict
resolutions, which are the only changes that were not in either parent. 

So for merge_into_workspace + fix language stuff, I need to subtract the
parent changesets from the revision changeset, in effect.

-- 
-- Stephe



reply via email to

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