Conflict handling

Aaron Bentley aaron.bentley at utoronto.ca
Mon Feb 13 17:13:52 GMT 2006


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

Aaron Bentley wrote:
> Yeah, I don't think it would be very intuitive, if you were looking for
> the files.  On the other hand, I suppose we could have
> 
> $ bzr merge --no-dump-conflicts
> and then also have
> $ bzr dump-conflicts $FILENAME
> to produce the conflicts (from .conflicts or .bzr/checkout/conflicts) if
> you decide you want them.

Err, there's a bug in this idea; it only works for text conflicts.

Another reason for dumping foo.THIS, foo.BASE and foo.OTHER is because
symlinks have different contents.  In this case, foo.OTHER will be a
versioned file.

Another reason for dumping foo.THIS, foo.BASE and foo.OTHER is because
the file types have changed (this is not presently permitted).

Another reason is because THIS has had its contents change, but OTHER
has been deleted.

Another reason is for binary file conflicts, where it's not meaningful
to perform a textual merge.  (This is not implemented yet, since we
don't really define 'binary' anywhere.)

In these cases, only foo.BASE, foo.THIS and foo.OTHER exist after the
merge.  There is no foo.  I suppose one option would be to use foo.OTHER
as foo.  (Or foo.THIS if foo.OTHER has been deleted.)

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD8L5Q0F+nu1YWqI0RAklXAJ9HNnLISg2ysZth9FJd5s+PDWkDogCeOGle
yL9L6ad0saYmQPKA2thafnA=
=6g2I
-----END PGP SIGNATURE-----




More information about the bazaar mailing list