Re: post-review problem
Sorry about that.
Background, this is a customized reviewboard 1.0 upgrade to 1.6.6.
Previous installation post-review had in python a VERSION = 0.8
Now I get:
RBTools 0.4.1
Home = /var/www
HTTP GETting api/
HTTP GETting https://127.0.0.1/reviewboard/api/info/
Using the new web API
There don't seem to be any diffs!
The
raw_outgoing = execute(['hg', '-q', 'outgoing', '--template',
'b:{branches}\nr:{rev}\n\n', remote],
env=self._hg_env,
extra_ignore_errors=(1,))
seems to give only https certificate errors.
Juhani
On May 4, 9:12 pm, Christian Hammond chip...@gmail.com wrote:
That latest error is from doing --server=--server=
Christian
On May 4, 2012, at 6:07, Juhani Tali juhani.t...@estneti.com wrote:
Hi,
I am not very comfortable with Python.
review-script is called from mercurial hook.
This is what I have found so far.
After fix for mercurial certificate warning messages
near error File /usr/local/lib/python2.6/dist-packages/rbtools/
clients/
mercurial.py, line 248, in _get_outgoing_changesets
branch, rev = pair.strip().split('\n')
try:
branch, rev = pair.strip().split('\n')
except ValueError:
if 'warning: ' in pair:
continue
Got a new error message:
www-data@squeeze:~/hg/.hg$ python /var/www/hg/.hg/review-script
0477768532d98c2a8cb25d92b2a95ab1e14a73e6
RBTools 0.4.1
Home = /var/www
HTTP GETting api/
HTTP GETtinghttps://127.0.0.1:443/reviewboard/api/info/
Using the new web API
There don't seem to be any diffs!
Mercurial sees:
www-data@squeeze:~/hg/.hg$ hg log -v -r
0477768532d98c2a8cb25d92b2a95ab1e14a73e6
changeset: 28890:0477768532d9
branch: t7702
parent: 28735:70bb78288793
parent: 28889:e169b5daf95b
user: username
date: Thu May 03 11:18:34 2012 +0800
files: application...
description:
sync ...
when running post-review, I got:
www-data@squeeze:~/hg/.hg$ post-review --server=--server=https://
127.0.0.1/reviewboard --submit-as=username --username=user --
password=password --publish --target-groups=USER_GROUPS --
summary='28890:0477768532d9' --description='long description' --
branch='t7702' --debug 0477768532d98c2a8cb25d92b2a95ab1e14a73e6
RBTools 0.4.1
Home = /var/www
HTTP GETting api/
Traceback (most recent call last):
File /usr/local/bin/post-review, line 9, in module
load_entry_point('RBTools==0.4.1', 'console_scripts', 'post-
review')()
File /usr/local/lib/python2.6/dist-packages/rbtools/postreview.py,
line 1222, in main
if not server.check_api_version():
File /usr/local/lib/python2.6/dist-packages/rbtools/postreview.py,
line 226, in check_api_version
root_resource = self.api_get('api/')
File /usr/local/lib/python2.6/dist-packages/rbtools/postreview.py,
line 669, in api_get
return self.process_json(self.http_get(path))
File /usr/local/lib/python2.6/dist-packages/rbtools/postreview.py,
line 639, in http_get
rsp = urllib2.urlopen(url).read()
File /usr/lib/python2.6/urllib2.py, line 126, in urlopen
return _opener.open(url, data, timeout)
File /usr/lib/python2.6/urllib2.py, line 391, in open
response = self._open(req, data)
File /usr/lib/python2.6/urllib2.py, line 409, in _open
'_open', req)
File /usr/lib/python2.6/urllib2.py, line 369, in _call_chain
result = func(*args)
File /usr/lib/python2.6/urllib2.py, line 1170, in http_open
return self.do_open(httplib.HTTPConnection, req)
File /usr/lib/python2.6/urllib2.py, line 1116, in do_open
h = http_class(host, timeout=req.timeout) # will parse host:port
File /usr/lib/python2.6/httplib.py, line 661, in __init__
self._set_hostport(host, port)
File /usr/lib/python2.6/httplib.py, line 686, in _set_hostport
raise InvalidURL(nonnumeric port: '%s' % host[i+1:])
httplib.InvalidURL: nonnumeric port: ''
On May 4, 5:27 am, Christian Hammond chip...@gmail.com wrote:
Hi,
Looks like some issue with the interpretation of the data coming from hg.
How comfortable are you with Python? It'd be helpful to see what data it's
operating on.
Christian
On May 3, 2012, at 0:41, Juhani Tali juhani.t...@estneti.com wrote:
Hi,
I am a bit stuck with post-review errors.
What could be the problem?
review-script starts post-review with comments etc.
Version control is mercurial.
www-data@squeeze:~/hg/.hg$ python /var/www/hg/.hg/review-script
0477768532d98c2a8cb25d92b2a95ab1e14a73e6
RBTools 0.4.1
Home = /var/www
HTTP GETting api/
HTTP GETtinghttps://127.0.0.1:443/reviewboard/api/info/
Using the new web API
Traceback (most recent call last):
File /usr/local/bin/post-review, line 9, in module
load_entry_point('RBTools==0.4.1', 'console_scripts', 'post-
review')()
File
Re: Final procedure for perforce integration?
Hi Christian, What's the procedure? I will need to let organization I work for know that before going forward. Thanks, -Neel. On Thursday, 12 April 2012 20:33:22 UTC+5:30, Christian Hammond wrote: Hi Neel, We really need to land a patch for proper ticket-based auth. The problem is that the existing patches broke existing Perforce accounts, as the tickets were assumed to be used. I need someone with an actual setup to test this and fix up a patch. I'll happily work with them on getting it into a 1.6.x release. Christian On Apr 10, 2012, at 1:11, Neel. neelag...@yahoo.com wrote: Hello, I have been setting my ticket (p4 login -a -p) as password EVERY day; ticket expires after 24 hours in my organization. I wanted to know have any other way have been finalized other than creating a user that has non-expiring ticket? I have searched lot about this and there are few review requests for reviewboard to make it password based or ticket based without needing user intervention but nothing seemed to have shipped it yet. Also, reviewboard is in domain and\or user is using his active directory username in domain\user format, and that same username \password is valid for perforce, is there a way to reuse that (possibly using some hooks?)? Thanks in advance, -Neel. -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- 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 -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- 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
Re: Problem with uploading consecutive diffs with updates
Can someone help me out here? On Wed, May 2, 2012 at 1:37 PM, Robert Dailey rcdailey.li...@gmail.comwrote: So I'm using Perforce and I upload my initial reviews (as well as follow up changes and updates) using this command. Note that this is a Custom Tool in P4V: %C --server=http://reviewboard.company.com --p4-client=$c --p4-port=$p --username=user --password=password %C is the changelist number in Perforce $c is the current workspace $p is the current port The problem I'm experiencing is updates to code in my changelist being included in my diffs in reviewboard. So suppose I have files checked out in my changelist. If I do a get latest from Perforce, and some of those checked out files get changed, and I resolve conflicts, those updates I pulled down will now show up in my diff. Reviewboard should not be showing these changes in my diff, in other words, Reviewboard needs to use the latest base of each file when diffing, which it does not. It continues to use the same revisions of the files that it originally used when the review was first created. Is there a fix for this? -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- 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
unable to create review request from post-review
Hi, I am using post-review 0.4.1 and I am unable to create review request: Following are the detailed logs: Failed to execute command: ['svn', 'info', '.xml'] ['.xml: (Not a versioned resource)\n','\n', 'svn: A problem occurred; see other errors for details\n'] Please help thanks Ashish -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- 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
Re: Problem creating a review after upgrading to 1.6.6 on CentOS 5.8 (patch file too large?)
Hey Alfred,
This is a database configuration issue. I don't know the key off-hand, but
you can increase the max packet size in MySQL.
That said, we do have a 1MB limit for diffs now (but that's not what you're
hitting), as Review Board can get bogged down if too many people are
processing large diffs at once. It's not configurable yet, but in general,
very large diffs can and should generally be avoided. They're quite hard to
review, and usually mean that there's some auto-generated code or something
in them that could be split out for the sake of review purposes.
Christian
--
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com
On Mon, May 7, 2012 at 12:08 PM, Alfred von Campe alf...@von-campe.comwrote:
I recently upgraded our ReviewBoard server to version 1.6.6. First,
thanks for a great product and an easy upgrade; the upgrade instructions
worked flawlessly. The issue described below may have nothing to do with
the upgrade, but I thought I'd mention it just in case.
Today a user complained to me that he can't create a new review via the
web interface and a patch file (i.e., not using post-review). Here is the
error log the server automatically generated (slightly redacted):
Traceback (most recent call last):
File
/usr/lib/python2.4/site-packages/Django-1.3.1-py2.4.egg/django/core/handlers/base.py,
line 111, in get_response response = callback(request, *callback_args,
**callback_kwargs)
File
/usr/lib/python2.4/site-packages/Djblets-0.6.16-py2.4.egg/djblets/auth/util.py,
line 46, in _checklogin return view_func(request, *args, **kwargs)
File
/usr/lib/python2.4/site-packages/ReviewBoard-1.6.6-py2.4.egg/reviewboard/reviews/views.py,
line 253, in new_review_request local_site=local_site)
File
/usr/lib/python2.4/site-packages/ReviewBoard-1.6.6-py2.4.egg/reviewboard/reviews/forms.py,
line 234, in create attach_to_history=True)
File
/usr/lib/python2.4/site-packages/ReviewBoard-1.6.6-py2.4.egg/reviewboard/reviews/forms.py,
line 286, in create history)
File
/usr/lib/python2.4/site-packages/ReviewBoard-1.6.6-py2.4.egg/reviewboard/diffviewer/forms.py,
line 142, in create filediff.save()
File
/usr/lib/python2.4/site-packages/Django-1.3.1-py2.4.egg/django/db/models/base.py,
line 460, in save self.save_base(using=using, force_insert=force_insert,
force_update=force_update)
File
/usr/lib/python2.4/site-packages/Django-1.3.1-py2.4.egg/django/db/models/base.py,
line 553, in save_base result = manager._insert(values,
return_id=update_pk, using=using)
File
/usr/lib/python2.4/site-packages/Django-1.3.1-py2.4.egg/django/db/models/manager.py,
line 195, in _insert return insert_query(self.model, values, **kwargs)
File
/usr/lib/python2.4/site-packages/Django-1.3.1-py2.4.egg/django/db/models/query.py,
line 1436, in insert_query return
query.get_compiler(using=using).execute_sql(return_id)
File
/usr/lib/python2.4/site-packages/Django-1.3.1-py2.4.egg/django/db/models/sql/compiler.py,
line 791, in execute_sql cursor = super(SQLInsertCompiler,
self).execute_sql(None)
File
/usr/lib/python2.4/site-packages/Django-1.3.1-py2.4.egg/django/db/models/sql/compiler.py,
line 735, in execute_sql cursor.execute(sql, params)
File
/usr/lib/python2.4/site-packages/Django-1.3.1-py2.4.egg/django/db/backends/mysql/base.py,
line 86, in execute return self.cursor.execute(query, args)
File
/usr/lib/python2.4/site-packages/MySQL_python-1.2.2-py2.4-linux-i686.egg/MySQLdb/cursors.py,
line 166, in execute
File
/usr/lib/python2.4/site-packages/MySQL_python-1.2.2-py2.4-linux-i686.egg/MySQLdb/connections.py,
line 35, in defaulterrorhandler
OperationalError: (1153, Got a packet bigger than 'max_allowed_packet'
bytes)
ModPythonRequest
path:/rb/r/new/,
GET:QueryDict: {},
POST:QueryDict: {u'parent_diff_path': [u''], u'changenum': [u''],
u'basedir': [u'branches/XX'], u'repository': [u'15']},
COOKIES:{'rbsessionid': 'f526a10b383c17b8e9b62dd8324badc4'},
META:{'AUTH_TYPE': None,
'CONTENT_LENGTH': '1035928',
'CONTENT_TYPE': 'multipart/form-data; boundary=
WebKitFormBoundaryrbuBf2aclFoD5s3R',
'GATEWAY_INTERFACE': 'CGI/1.1',
'HTTP_ACCEPT':
'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8',
'HTTP_ACCEPT_CHARSET': 'ISO-8859-1,utf-8;q=0.7,*;q=0.3',
'HTTP_ACCEPT_ENCODING': 'gzip,deflate,sdch',
'HTTP_ACCEPT_LANGUAGE': 'en-US,en;q=0.8',
'HTTP_CACHE_CONTROL': 'max-age=0',
'HTTP_CONNECTION': 'keep-alive',
'HTTP_CONTENT_LENGTH': '1035928',
'HTTP_CONTENT_TYPE': 'multipart/form-data; boundary=
WebKitFormBoundaryrbuBf2aclFoD5s3R',
'HTTP_COOKIE': 'rbsessionid=f526a10b383c17b8e9b62dd8324badc4',
'HTTP_HOST': 'hepdswsrv.X.com',
'HTTP_ORIGIN': 'http://hepdswsrv.X.com',
'HTTP_REFERER': 'http://hepdswsrv.X.com/rb/r/new/',
'HTTP_USER_AGENT': 'Mozilla/5.0 (Windows NT 6.1; WOW64)
AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.168 Safari/535.19',
Re: Problem creating a review after upgrading to 1.6.6 on CentOS 5.8 (patch file too large?)
On Mon, May 7, 2012 at 12:33 PM, Alfred von Campe alf...@von-campe.comwrote: On May 7, 2012, at 15:20, Christian Hammond wrote: That said, we do have a 1MB limit for diffs now (but that's not what you're hitting), as Review Board can get bogged down if too many people are processing large diffs at once. It's not configurable yet, but in general, very large diffs can and should generally be avoided. They're quite hard to review, and usually mean that there's some auto-generated code or something in them that could be split out for the sake of review purposes. Thanks for the quick response (as always). We were able to work around this by removing the project file from the patch file and that reduced the size sufficiently that it accepted the review. On a somewhat related issue, the performance of our ReviewBoard server (or lack thereof) has been a frequent source of complaints recently so I am probably going to set up a new server. What is the biggest factor affecting ReviewBoard performance? CPU speed, CPU count, available memory, disk speed, database, etc.? I'd like to configure a new server (or possibly a VM) appropriately to get better performance. What should I look out for? Alfred Memory and how much of it that memcached can use is crucial. We cache a *lot*, since fetching files from the repository, patching them, and generating diffs is all very expensive. So the more that memcached can hold at once, the faster things will feel all around. After that, you'll get some gains from database optimization and from increased CPU performance (for the diff generation). How big is your userbase, and what are your current specs? I know of servers with thousands of users that stand up under constant use. Usually it's just a configuration issue, or lack of memory for caching, that causes the most problems. Christian -- Christian Hammond - chip...@chipx86.com Review Board - http://www.reviewboard.org VMware, Inc. - http://www.vmware.com -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- 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
Re: Problem creating a review after upgrading to 1.6.6 on CentOS 5.8 (patch file too large?)
On May 7, 2012, at 16:56, Christian Hammond wrote: Memory and how much of it that memcached can use is crucial. We cache a *lot*, since fetching files from the repository, patching them, and generating diffs is all very expensive. So the more that memcached can hold at once, the faster things will feel all around. After that, you'll get some gains from database optimization and from increased CPU performance (for the diff generation). That's good to know. How big is your userbase, and what are your current specs? I know of servers with thousands of users that stand up under constant use. Usually it's just a configuration issue, or lack of memory for caching, that causes the most problems. A few dozen users and about 15 repos. It's on an older IBM xServer 335 with a 3.06GHz Intel Xeon CPU and 2GB or memory with 128MB configured for memcached. I've only recently enabled memcached, so I'm not 100% certain it is configured properly. Is there a way to query it to see what it has cached? Alfred -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- 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
