Re: [Monotone-devel] merge conflicts

[Hugo Cornelis]

This behavior makes it hard if not impossible to fully automate
regression testing for a software product.

>From viewpoint of the concepts, I would think that a merge conflict
resolution implemented by one user and pushed to a central repository,
would be honored automatically by repositories that only pull from
that central repository, such that these 'pull-only repositories' can
continue to serve their task.  But our experience indicates otherwise:
after manual resolution of all merge conflicts in one repository that
occasionally syncs with the central server, we still have to go
through other repositories that only pull from the server to resolve
what is essentially the same conflict.  This behavior just seems
incorrect.

I can understand that on occasion there is a merge conflict in the
puller's repository.  But it is still unclear to me why the merge
conflict on the puller's side persists, even after it has been
resolved in a different repository.

Is my understanding of this issue really correct?


Hugo


On Fri, Dec 11, 2009 at 2:03 PM, Mando Rodriguez
<address@hidden> wrote:
> 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
>>
>>
>>
>
>
> _______________________________________________
> Monotone-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/monotone-devel
>



-- 

Hugo


--

                    Hugo Cornelis Ph.D.

              Neurospaces Project Architect
                http://www.neurospaces.org/

                  Research Imaging Center
   University of Texas Health Science Center at San Antonio
                    7703 Floyd Curl Drive
                 San Antonio, TX  78284-6240

                    Phone: 210 567 8112
                      Fax: 210 567 8152