Conflict resolution workflow (was Re: Recipes vs. Looms vs. pipelines)

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Barry Warsaw wrote:
> On Dec 17, 2009, at 6:29 PM, Aaron Bentley wrote:
> 
>> If we did follow your approach, we'd have to decide
>> 1. which revision gets designated as the merge
>> 2. what do we do with the conflict metadata
>> 3. what do we do with the conflict files
>> 4. what should we do when checking out a revision with conflicts
>> 5. what should we do when merging a revision with conflicts
> 
> Honestly, I have no idea what the right thing to do is ;).  I'm mostly just stating the problem I guess.  Hopefully that's enough to get your much superior brain juices flowing. 
> 
>> Alternatively, it wouldn't be too hard to implement "diff -r merged:" as
>> a way of comparing the tree to its state immediately after the merge
>> completed.  That would give you a way to see what changes you had done
>> as part of merge resolution.
> 
> That would be a very good first (and sounds like, easy) step, especially if that can be done as I'm resolving the conflicts (i.e. before committing the results of the merge+resolve).
> 
> -Barry

The only issue is the flags you might pass to 'merge'. Like --weave,
- --reprocess, etc. Those tend to only get explicitly passed in complex
merge scenarios. But you also only need to share state in... complex
merge scenarios. :)

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksrxTUACgkQJdeBCYSNAANfKwCfRk1MbXNqUgw047ew1cT6HiNZ
Nc8AoK7QF6DBP+nDJw7a2KvPIZ2Yo8Hf
=24qy
-----END PGP SIGNATURE-----