"0 conflicts encountered."

[Jan Hudec]

On Tue, Dec 06, 2005 at 17:03:21 +1100, Martin Pool wrote:
> On  2 Dec 2005, Jan Hudec <bulb at ucw.cz> wrote:
> > On Fri, Dec 02, 2005 at 22:14:46 +0100, Matthieu Moy wrote:
> > > Aaron Bentley <aaron.bentley at utoronto.ca> writes:
> > > 
> > > >> And when are we thinking to switch to --merge-type=weave?
> > > >
> > > > I'm not sure.  I actually prefer three-way diffs, most of the time
> > > > - they give you a BASE file, so you can see what changes OTHER made.
> > > 
> > > AAUI, --merge-type does a 3-way merge at the file granularity (file
> > > names and meta-information), and a weave merge for file content. So,
> > > it shouldn't be difficult to put a file.BASE in the tree in case of
> > > conflict, right? (but I guess getting the ancestor in the conflict
> > > markers would be meaningless)
> > 
> > I am not really sure about it, but shouldn't the weave merge be equivalent to
> > 3-way merge if the base is well defined*? In that case, the logic could be:
> > Do 3-way merge if the ancestor is well defined, weave-merge otherwise.
> > 
> > * 3-way merge base is well defined if there is exactly one most recent common
> >   ancestor.
> 
> Yes, it should be at least very close to that behaviour.  The other
> difference would be that (as I recall) 3-way merge currently determines
> a single common ancestor for the whole tree, whereas weave merge
> determines the virtual ancestor per-file.  
> 
> I think we could fairly easily as the weave code to produce a BASE
> version as well: either the mushed-together virtual ancestor, or one
> ancestor text.  If there's a clear ancestor, they'll be the same thing.

... or it could provide all most recent ancestors...

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051206/6374c462/attachment.pgp