laserlight;11053141 wrote:So, is the resistance towards version control in general, or distributed version control, or Git in particular? I have been using distributed version control since that time in my first year of university where the Internet connection in the area I was doing project work failed for quite awhile, but I stuck with Bazaar until it became exceedingly clear that Bazaar simply could not compete with Git in its adoption, whereas Git overcame some of its weaknesses vis-a-vis Bazaar. However, I can understand if management is wary of distributed version control, or is reluctant to switch to another version control system, but I cannot understand how management would say no to version control in general, even if there is no solution in place for dealing with (the versioning of) database migration.
Pretty much any change to our workflow is met with resistance, so it's not exclusive to Git, but the idea of using some kind of VCS scares management. Mainly because it's misunderstood or just not understood at all. "What about X? What happens when Y occurs?" etc. whenever things come up that could change how we work now. No one at my work uses Git (aside from myself and a little with the coworker who is with me on our project). I bet some guys here don't even know what it is.
With that said, we did use SVN way back when I first started, but it wasn't used properly. In fact, I am not sure why it was used at all. We stopped using it around 4 years ago. In any case, SVN and Git are very different.
laserlight;11053141 wrote:As I may have mentioned elsewhere, I am actually more into Python these days, especially with the Django web framework. South, the most popular database migration tool for Django was eventually merged into Django itself. Basically, in Django, model classes are written, then Django introspects and generates SQL statements that are run to create the tables and indices. When a significant change to a model class is made, South (now Django) would be invoked to examine the change, then generate a Python script containing SQL statements that are then run to modify the database (or do data migrations instead of modifying the database), with dependencies on previous migrations specified so that multiple migrations can be applied in a correct order. Consequently, these Python scripts can be placed under version control, hence the migrations can be easily applied for other developers, or run with a post-commit hook, or run with a continuous integration server, etc. Just like code, it is possible for there to be conflicts, in which case
Of course, there is the other approach: the framework might have a tool that generates model classes by inspecting the database schema. I imagine that you could use a similiar approach, except that you would write the PHP scripts (to be under version control) that contain the SQL statements to be run. The catch perhaps is that if the framework's tool is applied automatically, you could end up with spurious conflicts in model class files if you place them under version control, but if you are doing manual changes to some parts of these files, you may need them under version control.
I guess the issue isn't necessarily recreating the database structure, but also its data.
Since WordPress is used, pretty much everything is stored in the database. If employee A is working on the project, he may install a plugin, which has its own files, but also makes several (maybe even hundreds) of entries in the database. Sharing the code with employee B via Git is relatively easy, but employee B may have installed a different plugin, and made his own changes to the database (added his own pages, posts, etc.). The challenge is to merge both the code (which is easy) but also the database.
Management likes the current setup because since the code and database is in one place, everything is as the left person who left it. Employee A can leave the project with plugin X installed and his work done, and employee B can come on board, do his plugins and entries and then leave, and employee A can come back and it's all there and can pick up where he left off with no time at all.
I probably have to do research on workflows with Git and WordPress and see how the developer community deals with it, and then come up with some kind of document explaining everything.
)
