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