You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you leave database/data/mysql_upgrade_info in your VVV directory, the data directory will continue to map. (Not recommended)
If you delete everything in the data directory, databases will persist inside the VM until it is destroyed. If you have the Vagrant Triggers plugin installed, databases will automatically backup on every vagrant halt, vagrant suspend, or vagrant destroy. You will want to leave readme.txt here as that is part of the repository.
Databases inside data/backups will continue to import if necessary during provisioning.
Update VVV to master or v1.2 tag.
And all is wonderful. Nice. I really did not expect it to go this well. :)
Just curious. If you are going through a box change in 1.2, so there isn't a direct upgrade path from 1.1 couldn't this be an opportunity to actually implement pr#460 which was closed because it would likely result in some issues with the existing naming of the running machines?
Two methods which I had originally found via SO which wasn't actually any clearer.
I will check to see if there are any points where your hostname fails to replace the default. I had also thought of perhaps reading the parent directory for naming the hostname. It would be dynamic and hopefully prevent collisions by allowing multiple vvvs on a single host by using different directory names.
Update: Read through the commit history for that line and realized it isn't related to what I had done. Still I would be curious if a 1.2 release with a change as large as the box might be a possible point to merge my pull request. I updated it with PR 512 which uses the folder name so even multiple instances of vvv could exist if they were in differently named folders.