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 at
> http://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.
