I wouldn't keep the database files in svn.
If you want to save the data in source control I recommend looking at
dumping the data into a json or yaml file. Then save that into source
control.
My workflow I use sqlite when running locally for dev purposes, but on
production it uses mysql. I have
Hi,
I started my project with a similar workflow but I soon ran into
troubles so I adopted the following one:
- svn repository has a production branch and a trunk
- my dev is done on trunk, on various machines (desktop, laptop, test
server)
- whenever I want to push something to the production s
Hernan Olivera wrote:
[...]
> Anyway, It was a little dataentry system. Now I am working in a bigger
> project with mysql or postgress, depending on performance issues. I
> will test both. (Django is my friend)
Hi Hernan!
Thank you very much for sharing your thoughts and experience, I
appreciate
Hi Fabio!
I have used a similark workflow withouth problems, no matters with the
db svn backup.
I have also deleted (sometimes renamed) my development db file to
prevent overwriting the svn version, but if you are ordered and write
appropiate messages when commit, it's easy to fix (I have commite
Hi Andy! Thanks for your kind reply.
Andy Mckay wrote:
[...]
> Best practice imho is not to use SQL lite for anything other than
> quickly playing around. I would strongly recommend postgres (other
> people my recommend others).
- I'll manage quite a small bunch of data, say personal informa
On 20-Mar-09, at 3:15 AM, Fabio Natali wrote:
> However, on updating the website, I must be very *careful* and run a
> selective update/merge: I must not overwrite the data.db file which is
> on the web server and actually the most important piece of the story.
Best practice imho is not to use S
6 matches
Mail list logo