Thadeus,
I can't say what Mike is doing, but what i tend to do with the
database (software setups very similar if not identical to those
mentioned) is that i have 2 bits:
- a script that will populate a database with dummy data if it is
empty. I use this for bringing up new machines and getting a quick
sanity check that the install was correct.
- i use my production database backups on my local machine. (you
should have a backup plan...this is a useful way to test it) This
only works while the DB is still small enough to run on your machine,
which for me has been true for about 90% of the projects i work on.
hope that helps! good luck!
cfh
On Feb 9, 2:01 pm, Thadeus Burgess <thade...@thadeusb.com> wrote:
> Mike, how are yall testing changes locally before you commit?
>
> Does each developer have his own version of the database in sqlite
> with different data?
>
> -Thadeus
>
> On Tue, Feb 9, 2010 at 3:39 PM, MikeEllis <michael.f.el...@gmail.com> wrote:
> > FWIW, the following approach is working for us with a small team of
> > developers. We use SVN instead of mercurial, but I don't see why this
> > wouldn't work for mercurial.
>
> > 1. All the python, html, and static files (and _nothing_ else) in our
> > app's directory tree are under version control in a separate
> > repository. The nothing else part is really important.
>
> > 2. We're keeping migrate=True on the table definitions. It's not
> > bitten us yet, but keep in mind that we're using SQLite and the
> > CherryPy server that comes with web2py.
>
> > 3. Each developer installs a local copy of web2py and then checks out
> > our app under web2py/applications .
>
> > 4. When a developer feels a change is ready to commit, s/he does so in
> > the usual way.
>
> > 5. We keep a remote test instance of web2py and the latest version of
> > the app running in a Rackspace cloud server. This is mostly for
> > spotting things that behave differently remotely (and catching the
> > situation where someone forgets to a version control a new
> > file, ...). All the developers are authorized to private-key ssh into
> > the remote web2py user account to manually update the app in the test
> > server instance.
>
> > 6. We found it useful to put a little bit of SVN magic into our
> > menu.py to make the application subtitle display the current rev no.
>
> > try:
> > import pysvn
> > svncli = pysvn.Client()
> > svninfo = svncli.info('applications/init')
> > svnrev = svninfo.revision.number
> > response.subtitle = T('Interface Prototype: Revision %s'%svnrev)
> > except:
> > response.subtitle = T('Interface Prototype')
>
> > Updating the app into a running web2py instance seems to be no
> > problem. The only time we have to stop a server is to update the
> > web2py version. So far the 'unzip on top of the installation' method
> > is working with no problems.
>
> > Hope this is useful.
>
> > Cheers,
> > Mike
>
> > On Feb 9, 2:35 pm, Dmitri Zagidulin <dzagidu...@gmail.com> wrote:
> >> FWIW, I do multi user development on web2py, and take the route that
> >> you describe -- not version the .table files, and do a migrate=False
> >> on all the tables in the model. This is partly because of multi
> >> developer collisions, and partly because the migrate functionality
> >> does not work for the web2py version/odbc drivers/database engine
> >> we're using (ms sql).
>
> >> The developers all work off of a shared database (using a two-tiered
> >> approach actually, a 'dev' database everybody works off of, and a live
> >> db).
> >> This basically works out nicely -- if a dev adds or creates a column,
> >> they do it directly on the dev database, and commit the changes to
> >> db.py. There is also a person in charge of the live database schema --
> >> the schema (sql create files) gets tracked separately in version
> >> control.
>
> >> On Feb 9, 1:38 pm, Thadeus Burgess <thade...@thadeusb.com> wrote:
>
> >> > I have thought about setting up a shared postgres. However the issue
> >> > still remains that if the .table files are altered during two
> >> > branches, when merging how do you pick which .table file to accept?
>
> >> > And you can't get rid of .table files because then you would not be
> >> > able to connect to the postgres database.
>
> >> > Would it work if we did not version the .table files, and set
> >> > fake_migrate = True on all of the define_table statements? Then would
> >> > we be able to still have automatic migrations?
>
> >> > -Thadeus
>
> >> > On Tue, Feb 9, 2010 at 4:38 AM, tiago almeida
> >> > <tiago.b.alme...@gmail.com> wrote:
> >> > > hy not setup a shared db server on the network? It works, just needs
> >> > > some
> >> > > coordination when making changes to the model. Does it have to be sql
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "web2py-users" group.
> > To post to this group, send email to web...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > web2py+unsubscr...@googlegroups.com.
> > For more options, visit this group
> > athttp://groups.google.com/group/web2py?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
