resolve conflicts with multiple persons

[Simon King]

On Tue, Jul 7, 2015 at 1:24 PM, Ike Casteleyn <icasteleyn at hotmail.com> wrote:
> Hi,
>
> We are undertaking a major merge between 2 branches (read: a few years
> apart).
> To make this 'easier' we want to resolve the conflicts with multiple persons
> (instead of one poor soul doing all the work).
>
> First possibility:
> Commit the merge with all unresolved conflicts and then each developer can
> resolve conflicts on his machine.
> We communicate who resolves which files.
> Commiting unresolved conflicts isn't allowed, so this possibility isn't
> possible.
>

While it isn't possible to commit unresolved conflicts, it is possible
to mark all the files as resolved ("hg resolve -m"), and commit the
result. The developers could then fix up the files they are
responsible for in separate commits. You'd want to keep track of the
files that were originally marked unresolved, and you'd need to
execute your merge tools by hand because mercurial won't launch them
for you. I wouldn't do it this way though, see below.

> Second possibility:
> I created a clone on a shared folder and did the merge there.
> We don't need to commit, but each developer can resolve conflicts in the
> shared location (again communicating who resolves which files).
> Problem here is that the working copy gets locked when you open a file in
> mergetool and all other devs need to wait now.
> Perhaps I could delete the wlock file to get passed this, but that seems
> 'dangerous'.
>
> Is it possible to do this in a safe way?
> Or if not possible in a safe way, in an unsafe way (and what would the risks
> be then)?
>

Each developer could run the same "hg merge" command on their local
machine, fix the files that they are responsible for, and send them to
a person acting as integrator. The integrator runs the same merge
command then adds the files received from each developer, using "hg
resolve -m" to mark them as resolved. As long as everyone is merging
the same 2 revisions, there shouldn't be any risks in this approach.

Hope that helps,

Simon