Joseph Method wrote:
A couple things.
The problem lies mainly in my own master branch: I merge bsag/master
into this, but I also do my own work in this and use this branch to
actually use tracks.
I wouldn't do this. I would use three branches: 1)github master, 2)
local cloned branch for development 3) second local clone for
deployment/production that you update less often than the development
branch. This makes sense especially if you have a "customer" (like my
girlfriend) who uses Tracks on a day to day basis and doesn't want to
beta-test every little change.
So you can git pull from bsag/master to your local development branch,
merge and commit the changes, then push to the remote github master,
then from the deployment instance you git pull from the github master
(hope that makes sense).
I would also change your database.yml (which should *not* be in
version control) to use a different sqlite3 file, and the sqlite3 file
should never be in version control. If you're worried about adding it
with git add *, you can add an ignore line in the .gitignore file in
the root of the repository. If you're serving multiple users I would
use mysql anyway (I don't think sqlite3 does concurrency very well,
right?).
--
-J. Method
Good idea: working with a separate clone instead of another branch in
the same clone:
-> I don't need to switch branches the whole time
-> I can run both applications at the same time on other ports
-> I avoid accidentally pushing personal stuff to github.
I'm the only consumer of the application, so sqlite is just fine for me :)
Here's an idea: in the development clone I can set the development
database to an sqlite3 database (just a development database. nothing
unusual here), but I can also make use of the "production" environment
of the development clone to point to my real production database (or
better: a copy of it). That way I can use (a copy of) my production
data to easily reproduce bugs, and check if new features will work in
(my) production (testing other scenarios is still a must of course, if
applicable), avoiding the need for multiple commit-push-pull cycles. (or
the need to manually populate the database with more data).
config/database.yml is in .gitignore, so you can edit that without
accidentally committing it.
That, in combination with storing *.db files outside of the git clone
will make a powerful setup I think (and no need to add more stuff to
.gitignore)
Dieter
_______________________________________________
Tracks-discuss mailing list
[email protected]
http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss
