3 ms·
1. Like what? 2. I know, but you did ask. I wouldn't bother incrementally changing the schema for such a small project - I'd just throw the dumps in version co
by debacle 14y ago
1. Like what?
2. I know, but you did ask. I wouldn't bother incrementally changing the schema for such a small project - I'd just throw the dumps in version control. I'd roll back in the same fashion.
I guess we have different definitions of 'simple web project.' I'm thinking a 100-200 hour project that's going to see 5k visits per day, max. What are you thinking?
- doc4t 14y ago1. Like modules which are temp. disabled for instance. You could argue of course that these modules should then not exist in the production branch. Also reference images, project notes etc. 2. I could do that but I'm trying to learn how to do it properly...as in I imagine there would be a better way for this. When the DB (hopefully )grows to a considerable size then I take it this approach is not feasible. The project is ongoing and I lost track of the hours many years ago. 5K users! Ha - I wish :) I was thinking about my general project setup which is described in the initial question...I'm just wondering whether there would not be a more structure way to solve this problem.
- mh- 14y agoyou fork the branch and have one that is 'deployable'. every time you want to do a deployment, tag it with an incrementing version number. checkout said tag into apache's webroot. for managing migrations, I don't have specific experience w/ PG but this looks decent: http://www.liquibase.org/home http://www.liquibase.org/home