Hi, MARK!
On Jun 18, MARK CALLAGHAN wrote:
...
> I get lots of conflicts like this:
> Text conflict in sql/slave.cc
> Conflict: can't delete storage/innodb_plugin.moved because it is not
> empty. Not deleting.
> Conflict adding file storage/innodb_plugin. Moved existing file to
> storage/innodb_plugin.moved.
> Conflict because storage/innodb_plugin.moved is not versioned, but has
> versioned children. Versioned directory.
> Conflict: can't delete storage/innodb_plugin.moved/btr because it is
> not empty. Not deleting.
> Conflict because storage/innodb_plugin.moved/btr is not versioned, but
> has versioned children. Versioned directory.
> Contents conflict in storage/innodb_plugin.moved/btr/btr0btr.c
> Contents conflict in storage/innodb_plugin.moved/btr/btr0cur.c
> Contents conflict in storage/innodb_plugin.moved/btr/btr0pcur.c
> Contents conflict in storage/innodb_plugin.moved/btr/btr0sea.c
,,,
> The contents of r3366 might be interesting. It looks like
> storage/innodb_plugin was recursively deleted and then added by this
> change.
Right, that's how I understood it too.
We've had the fun of merging it in MariaDB.
But our merge was easier as we don't modify innodb_plugin, so I've
simply deleted all *.moved files and directories.
You'll need to move your changes manually from innodb_plugin.moved to
innodb_plugin, loosing all the history, of course :(
> Why was that done?
I guess, somebody upgraded innodb_plugin in MySQL source tree to a new
version (from innodb svn, perhaps?), and instead of replacing files
under bzr nose (rm -rf innodb_plugin; cp -r ~/new/innodb_plugin .)
decided to inform bzr that old tree is deleted (bzr rm -force innodb_plugin).
Somebody may speculate that it was done to complicate the work of
maintaining forked innodb_plugin branches, but I personally don't
attribute it to malice.
> Does that mean that people like me who maintain our own trees and want
> to merge now have a lot more work to do?
Only once, when you merge this changeset.
Regards,
Sergei
