List:Internals« Previous MessageNext Message »
From:Sergei Golubchik Date:June 19 2010 8:14am
Subject:Re: questions about merging the facebook patch to tag:mysql-5.1.47
View as plain text  
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

Thread
questions about merging the facebook patch to tag:mysql-5.1.47MARK CALLAGHAN18 Jun
  • Re: questions about merging the facebook patch to tag:mysql-5.1.47MARK CALLAGHAN19 Jun
  • Re: questions about merging the facebook patch to tag:mysql-5.1.47Sergei Golubchik19 Jun
    • Re: questions about merging the facebook patch to tag:mysql-5.1.47Konstantin Osipov19 Jun
      • Re: questions about merging the facebook patch to tag:mysql-5.1.47Sergei Golubchik19 Jun
        • Re: questions about merging the facebook patch to tag:mysql-5.1.47Konstantin Osipov19 Jun
          • Re: questions about merging the facebook patch to tag:mysql-5.1.47Sergei Golubchik19 Jun
            • Re: questions about merging the facebook patch to tag:mysql-5.1.47Konstantin Osipov19 Jun
    • Re: questions about merging the facebook patch to tag:mysql-5.1.47MARK CALLAGHAN19 Jun
    • Re: questions about merging the facebook patch to tag:mysql-5.1.47Stewart Smith21 Jun
      • Re: questions about merging the facebook patch to tag:mysql-5.1.47Vasil Dimov21 Jun
        • Re: questions about merging the facebook patch to tag:mysql-5.1.47Stewart Smith22 Jun
  • Re: questions about merging the facebook patch to tag:mysql-5.1.47Konstantin Osipov19 Jun
    • Re: questions about merging the facebook patch to tag:mysql-5.1.47MARK CALLAGHAN19 Jun
      • Re: questions about merging the facebook patch to tag:mysql-5.1.47Konstantin Osipov19 Jun
  • Re: questions about merging the facebook patch to tag:mysql-5.1.47Davi Arnaut19 Jun
    • Re: questions about merging the facebook patch to tag:mysql-5.1.47MARK CALLAGHAN19 Jun
      • Re: questions about merging the facebook patch to tag:mysql-5.1.47Davi Arnaut19 Jun
  • Re: questions about merging the facebook patch to tag:mysql-5.1.47Vasil Dimov21 Jun