Interpreting .pyc files is more efficient than interpreting .py files, but Apache should still be able to handle .py files without problems. A .pyc file isn't actually needed. I don't know why it wouldn't be picking up your changes. I've done this many times without issues.
If you absolutely want to make sure a .pyc is generated, you can probably change directory ownership for the directory containing the .py file to be owned by the web server, or make the directory world-writable. Also, the whole restarting Apache thing was based on an assumption that you're using mod_python. If you're using fastcgi (which, btw, I'd recommend against due to some memory issues we've seen on a number of servers), then that's a bit different. You'll want to restart the fastcgi server instance. Christian -- Christian Hammond - chip...@chipx86.com VMware, Inc. On Thu, Dec 18, 2008 at 2:47 AM, KunalG <kunal.gosw...@gmail.com> wrote: > > Well, may be I will create another RB site after checkout from SVN and > then redirect existing one to this when everything is synchronized. > But since this is already used by some of us, we need to configure it > soon and may need to compile email.py. Kindly let me know if there is > any procedure to do that. > I have removed email.pyc but this is not getting created again. > > Thanks, > Kunal > > > > > On Dec 18, 3:30 pm, "Christian Hammond" <chip...@chipx86.com> wrote: > > I'd strongly recommend grabbing SVN, modifying that, and then building > your > > own installables. > > > > The reason why is that at some point you're going to want to upgrade, and > > it's going to be very hard to keep those changes in sync. You'll need a > diff > > between your version and that actual nightly, but that probably won't > apply > > in the future (especially with the UI rewrite change that's going in > soon). > > > > If you use SVN and do development there, you shouldn't have a problem > with > > Apache not seeing the updates, and you'll be able to stay upgraded well > > enough. All you have to do is grab the SVN tree, make whatever changes, > and > > then run "sudo python setup.py install" to get the installed version of > > that. > > > > Christian > > > > -- > > Christian Hammond - chip...@chipx86.com > > VMware, Inc. > > > > On Thu, Dec 18, 2008 at 2:23 AM, KunalG <kunal.gosw...@gmail.com> wrote: > > > > > I am directly making changes in the installed version and not using > > > SVN checkout. > > > Well I removed the .pyc file (actually renamed it to some other, > > > thinking it should work) and then restarted apache but the changes > > > were not picked. I confirmed this with the modified time of the .pyc > > > file earlier but after renaming, new .pyc was not created. > > > > > Changes that I am making are particular to our use only. Like > > > 1. Only the request submitter is allowed to view 'Set Submitted' on > > > the review page. Reviewers can only provide their comments and then > > > approve by clicking 'ship it' > > > > > 2. Once approved by all reviewers, only the request submitter can post > > > this into our tracking system which I think is an internal tool for > > > us. The report will directly get attached to the bug system. This is > > > basically just a separate form with all the fields filled from the > > > request and then automatic form submission using Javascript. > > > > > 3. Some installation steps provided for the client side to use 'post- > > > review.py' which asks for the bug ID first. > > > > > Thanks, > > > Kunal > > > > > On Dec 18, 2:40 pm, "Christian Hammond" <chip...@chipx86.com> wrote: > > > > Are you using an SVN checkout, or modifying files in the installed > > > version? > > > > These files exist in the SVN checkout only, but if you're modifying > the > > > > production copy directly, you can modify the .py files, remove the > .pyc > > > > files, and then restart Apache to reload them. > > > > > > What kinds of changes are you making? Perhaps some of it can make its > way > > > > into Review Board in some form. > > > > > > Christian > > > > > > -- > > > > Christian Hammond - chip...@chipx86.com > > > > VMware, Inc. > > > > > > On Thu, Dec 18, 2008 at 1:22 AM, KunalG <kunal.gosw...@gmail.com> > wrote: > > > > > > > well, I have already made some changes to review board, so may not > be > > > > > in a position to install the production copy again. > > > > > > > For second, I dont see any settings_local.py.tmpl and devserver.sh > > > > > Is this added new or is their any other way also. > > > > > > > Thanks, > > > > > Kunal > > > > > > > On Dec 18, 2:10 pm, "Christian Hammond" <chip...@chipx86.com> > wrote: > > > > > > You can run "sudo python setup.py install" to install a > production > > > copy. > > > > > > > > If you're doing pure development, you can just copy > > > > > settings_local.py.tmpl > > > > > > to settings_local.py, set the stuff inside, run ./devserver.sh in > the > > > > > > reviewboard directory and connect to the IP shown. > > > > > > > > Adding a bugs field to the dashboard is probably going to be > really > > > easy. > > > > > > It's a simple subclass of a Column (see reviews/datagrids.py) and > an > > > > > entry > > > > > > in the right DataGrid subclass. > > > > > > > > Christian > > > > > > > > -- > > > > > > Christian Hammond - chip...@chipx86.com > > > > > > VMware, Inc. > > > > > > > > On Thu, Dec 18, 2008 at 1:02 AM, KunalG <kunal.gosw...@gmail.com > > > > > wrote: > > > > > > > > > What are the steps to compile the site again, if I make changes > in > > > > > > > some of the .py file for my local usage. > > > > > > > Actually I want to customize the email that is send and i made > > > changes > > > > > > > in email.py but my changes are not picked and .pyc file is > still > > > the > > > > > > > old one. > > > > > > > > > Thanks, > > > > > > > Kunal > > > > > > > > > On Dec 18, 1:59 pm, KunalG <kunal.gosw...@gmail.com> wrote: > > > > > > > > ya what you say holds to us as well and had this in mind but > > > thought > > > > > > > > to check if something like this is provided. > > > > > > > > We will try to find a solution to display the bug ID and the > > > review > > > > > > > > request number in the dashboard itself along with review > summary. > > > > > > > > > > Thanks, > > > > > > > > Kunal > > > > > > > > > > On Dec 18, 12:32 pm, "Christian Hammond" < > chip...@chipx86.com> > > > > > wrote: > > > > > > > > > > > Hi. > > > > > > > > > > > There's no API at this time for looking up a review request > by > > > a > > > > > bug > > > > > > > ID. > > > > > > > > > This could be added if someone wants to write a patch, but > it's > > > > > > > important to > > > > > > > > > note a few things: > > > > > > > > > > > 1) This will have to be per-repository, since you can have > two > > > > > > > different > > > > > > > > > bugs on two different trackers that have the same number. > > > > > > > > > > > 2) It's not uncommon in many cases for multiple review > requests > > > to > > > > > > > reference > > > > > > > > > the same bug number. This can't be broken. Any API function > > > > > returning > > > > > > > review > > > > > > > > > requests must provide a list. > > > > > > > > > > > 3) There's no fast, clean way to index bug numbers, so > > > searching is > > > > > > > going to > > > > > > > > > be slow. This is probably going to be a blocker, really. > > > > > > > > > > > Why can't people use their dashboard to find these review > > > requests? > > > > > We > > > > > > > may > > > > > > > > > want to look at the core problem -- people not remembering > the > > > > > review > > > > > > > > > request ID -- and figure out why this is a problem there. > > > > > > > > > > > Christian > > > > > > > > > > > -- > > > > > > > > > Christian Hammond - chip...@chipx86.com > > > > > > > > > VMware, Inc. > > > > > > > > > > > On Wed, Dec 17, 2008 at 11:17 PM, KunalG < > > > kunal.gosw...@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > Hi Devs, > > > > > > > > > > > > Right now we are testing Review board and uptill now it > feels > > > > > great > > > > > > > to > > > > > > > > > > use this. We have already customized it to a good extent > to > > > > > integrate > > > > > > > > > > it with some of other used systems. > > > > > > > > > > Now the questions is we have a bug ID that we submit at > the > > > time > > > > > of > > > > > > > > > > posting request. That gets attached to the review request > but > > > if > > > > > we > > > > > > > > > > want to submit file changes again to that bugID, we need > to > > > know > > > > > the > > > > > > > > > > review request number which users may not be remembering > > > every > > > > > time. > > > > > > > > > > For us they will be knowing the bug Id. So our > requirement is > > > if > > > > > we > > > > > > > > > > provide the bug ID it should go to the same request. > > > > > > > > > > > > How can this be done? Is there API that is provided to > get > > > the > > > > > review > > > > > > > > > > request number for a bug ID. Then we can proceed that > way. > > > > > > > > > > > > Thanks, > > > > > > > > > > Kunal > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "reviewboard" group. To post to this group, send email to reviewboard@googlegroups.com To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -~----------~----~----~----~------~----~------~--~---
