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
_______________________________________________ Tracks-discuss mailing list [email protected] http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss
