hg diff on MySQL Workbench files

前端 未结 1 1402
误落风尘
误落风尘 2021-01-22 21:33

I\'m posting this as a Q&A to document a workaround for a problem that seems to come up frequently—how to put MySQL Workbench files under version control—but for which I

相关标签:
1条回答
  • 2021-01-22 22:03

    I have not found a true solution, but I have developed a satisfactory workaround, inspired by this mwb-diff gist. This allows me to unzip and diff the .mwb file's contents, commit those contents and their changes to the repository, and use the .mwb normally when necessary.

    Project Structure

    My project is set up like this:

    project_root
        /dist
        /schema
        /src
        /test
    

    I save the .mwb file - call it MyModel.mwb - in project_root/schema. Obviously, you can use a different structure, but you will need to modify the instructions below accordingly.

    The Scripts

    I created the following scripts and saved them in project_root/schema:

    unpack.sh

    #!/bin/bash
    
    # Unzip the model (MyModel.mwb) into a particular directory (project_root/schema/MyModel)
    unzip -o MyModel.mwb -d MyModel/
    
    # Replace all _ptr_="...." attributes with _ptr_="xxx"
    sed -i presed -E 's/_ptr_="0x[0-9a-f]+"/_ptr_="xxx"/g' MyModel/document.mwb.xml
    

    pack.sh

    #!/bin/bash
    
    # This file goes into the directory containing the model contents, zips them up, and saves them as a .mwb model
    
    cd MyModel/
    zip -r ../MyModel.mwb ./* -x lock
    cd ..
    

    Getting Mercurial Ready to Rock

    We need to tell hg to ignore the model (and all other .mwb files). Also, when MySQL Workbench is open, it adds a lock file to the .mwb archive, which we need to ignore. So, add these lines to your .hgignore file:

    *.mwb
    *.mwb.bak
    schema/MyModel/lock
    

    An Aside About the data.db File

    Optionally, also ignore the data.db file (a SQLite database) in the .mwb file. It is a binary file that contains any INSERTs or other non-create SQL statements that are part of your model. As a rule, I don't use MySQL Workbench for this stuff; I use it only to create and edit tables, views, etc. So, I added this line to .hgignore:

    schema/MyModel/data.db
    

    If you want to track changes to the data.db file, you may need to modify this workaround.

    How to Use the Scripts

    When you want to modify the .mwb file, rebuild it from its components by running pack.sh above. This could be added as a hook to happen automatically when you hg pull, update, etc., but I haven't explored this, yet.

    When you are done editing the .mwb file and want to commit your changes, run the unpack.sh script. If you want, you can set up a file-watching utility on your system to do this automatically when the file changes, but that's beyond the scope of this answer.

    The Results

    Mercurial is now perfectly happy to track changes to the contents of your .mwb file without tracking thousands of apparently-useless _ptr_ attributes. Also, while I am using this with Mercurial, the basic logic (and the shell scripts) will work with git, SVN, etc.

    IMPORTANT CAVEAT: As far as I can tell, the _ptr_ attributes are irrelevant. The scripts I have posted above actually replace the contents of those attributes. _ptr_="0x98a7b3e4" (or whatever) becomes _ptr_"xxx". Based on my testing, this doesn't matter, and MySQL Workbench will happily work with the reconstituted file, apparently disregarding the _ptr_ values. I may be wrong, and these values may matter! You are strongly encouraged to test this for yourself before relying on my solution.

    0 讨论(0)
提交回复
热议问题