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 at http://groups.google.com/group/web2py?hl=en.
