monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] merge conflicts


From: Mando Rodriguez
Subject: Re: [Monotone-devel] merge conflicts
Date: Fri, 11 Dec 2009 14:03:42 -0600

Thank you!

Is it feasible to distinguish a repository that allows automated
merges from one that does not using monotone variables?

-Mando

On Fri, Dec 11, 2009 at 6:20 AM, Thomas Keller <address@hidden> wrote:
> Am 11.12.2009 09:34, schrieb Mando Rodriguez:
>> Hi Thomas,
>>
>> Thanks for the explanation, was very helpful for understanding that 
>> situation.
>>
>> Just some follow up questions.
>>
>> How can we make sure that an automated robot that pulls from a server
>> repository never gets stuck on a merge conflict?
>
> Never, because there are no options which make a monotone merge
> automatically take "all-the-left" or "all-the-right", which might not be
> wanted anyways. I might have said that most merges are no-brainers in
> monotone, but of course a couple of merges popup content or tree
> conflicts and some of those can't be resolved automatically.
>
>> Is there anything as far as server side options for the repository or
>> client side options for the automated robot that can be used to reduce
>> conflicts? Or possibly to ensure that the properly merged states from
>> the users who perform check ins propagate to the automated robot?
>
> The simplest way is to only let the robot test for possible merges. This
> is as simply as checking if there are multiple heads for a branch, like
>
> $ mtn automate heads your.branch
>
> If this returns more than one line, you have multiple heads and need to
> merge (automatically or by hand).
>
> If you'd like to do this automatically, then you'd try out the merge at
> first, by iterating over every revision returned from automate heads and
> call f.e. for four heads:
>
> $ mtn explicit_merge R1 R2 your.branch # creates M1
> $ mtn explicit_merge M1 R3 your.branch # creates M2
> $ mtn explicit_merge M2 R4 your.branch
>
> If all of the merges succeed, then fine, go ahead and test the merged
> revision. If not, use
>
> $ mtn automate show_conflicts -b your.branch LEFT RIGHT
>
> to return the conflicts in a machine-readable format and send this
> information to a developer with the advice to merge the two revisions.
> Unfortunately the show_conflicts command isn't very useful to use before
> you merge, because it might report f.e. content conflicts which the
> internal monotone line merger might be perfectly able to resolve on its own.
>
> Lastly, you can of course also either opt-in and let the robot test
> every head it encounters or opt-out and test nothing unless you find a
> single head, and therefore don't care about automated merging at all.
>
> Thomas.
>
> --
> GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
> Please note that according to the EU law on data retention, information
> on every electronic information exchange might be retained for a period
> of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en
>
>
>




reply via email to

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