Re: rbt post fails with git cat-file: could not get object info
Thanks Christian. Our RB server keeps a local repository, and pulls via
cron job to stay current. When we checked that local repository, there were
merge conflicts, so all the pulls had been failing for a few days. I have
no idea why that repository would have merge conflicts, but we reset and
now all is well. Thanks again for your reply. That was the clue that set us
on the right track to resolve the issue.
On Friday, March 3, 2017 at 4:01:22 PM UTC-5, Christian Hammond wrote:
>
> Hi Greg,
>
> Are older diffs in Review Board able to load? (Ones that would have fallen
> out of cache). I'm curious if this is something affecting only newer diffs.
>
> This is often due to changes on the Git repository. Mirroring may be
> failing, for instance, if this is a clone of the main repository.
>
> Might want to also manually run some commands on that Git repository and
> see if the state of the tree looks correct.
>
> Christian
>
>
> On Fri, Mar 3, 2017 at 09:15 Greg Burcher > wrote:
>
>> Not sure what has changed in our configuration or repository that could
>> be the problem. We have been using reviewboard for a couple of years. In
>> the past couple of days, "rbt post" is failing for multiple users with:
>>
>> rbtools.commands.CommandError: Error validating diff
>>
>> The specified diff file could not be parsed. (HTTP 400, API Error 224)
>>
>> I used --debug and got this detail, with certain fields obfuscated:
>>
>> $ rbt post --debug --tracking-branch=origin/myTrackingBranch
>> >>> RBTools 0.7.4
>> >>> Python 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit
>> (Intel)]
>> >>> Running on Windows-7-6.1.7601-SP1
>> >>> Home = C:\Users\myUserName\AppData\Roaming
>> >>> Current directory = C:\myDirectory
>> >>> Running: git version
>> >>> Checking for a Subversion repository...
>> >>> Unable to execute "svn help": skipping SVN
>> >>> Checking for a Git repository...
>> >>> Running: git rev-parse --git-dir
>> >>> Running: git config core.bare
>> >>> Running: git rev-parse --show-toplevel
>> >>> Running: git symbolic-ref -q HEAD
>> >>> Running: git config --get branch.myBranchName.merge
>> >>> Command exited with rc 1: ['git', 'config', '--get',
>> u'branch.myBranchName.merge']
>> ---
>> >>> Running: git config --get branch.myBranchName.remote
>> >>> Command exited with rc 1: ['git', 'config', '--get',
>> u'branch.myBranchName.remote']
>> ---
>> >>> Running: git config --get remote.origin.url
>> >>> repository info: Path:
>> https://myUserName@myGitServer/bitbucket/scm/myRepository.git, Base path: ,
>> Supports changesets: False
>> >>> Making HTTP GET request to http://myReviewBoardServer/api/
>> >>> Running: git rev-parse refs/heads/myBranchName
>> >>> Running: git merge-base 71f1767180902f1cf6b3defbc8d5a9869576bf25
>> origin/myTrackingBranch
>> >>> Running: git rev-parse 2250f117eedb858afeaf824e2c45b22246a1d2fa
>> >>> Running: git status --porcelain --untracked-files=no
>> >>> Running: git rev-parse --git-dir
>> >>> Running: git -c core.quotepath=false -c diff.noprefix=false diff
>> --no-color --full-index --ignore-submodules -M --no-ext-diff
>> 2250f117eedb858afeaf824e2c45b22246a1d2fa..71f1767180902f1cf6b3defbc8d5a9869576bf25
>> >>> Making HTTP GET request to
>> http://myReviewBoardServer/api/validation/diffs/
>> >>> Cached response for HTTP GET
>> http://myReviewBoardServer/api/validation/diffs/ expired and was modified
>> >>> Making HTTP POST request to
>> http://myReviewBoardServer/api/validation/diffs/
>> >>> Got API Error 224 (HTTP code 400): The specified diff file could not
>> be parsed.
>> >>> Error data: {u'stat': u'fail', u'reason': u'fatal: git cat-file:
>> could not get object info\n', u'err': {u'msg': u'The specified diff file
>> could not be parsed.', u'code': 224}}
>> Traceback (most recent call last):
>> File "C:/tools/RBTools/bin/../Python27/Scripts/rbt-script.py", line 8,
>> in
>> load_entry_point('RBTools==0.7.4', 'console_scripts', 'rbt')()
>> File
>> "C:\tools\RBTools\Python27\lib\site-packages\rbtools-0.7.4-py2.7.
rbt post fails with git cat-file: could not get object info
Not sure what has changed in our configuration or repository that could be
the problem. We have been using reviewboard for a couple of years. In the
past couple of days, "rbt post" is failing for multiple users with:
rbtools.commands.CommandError: Error validating diff
The specified diff file could not be parsed. (HTTP 400, API Error 224)
I used --debug and got this detail, with certain fields obfuscated:
$ rbt post --debug --tracking-branch=origin/myTrackingBranch
>>> RBTools 0.7.4
>>> Python 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit
(Intel)]
>>> Running on Windows-7-6.1.7601-SP1
>>> Home = C:\Users\myUserName\AppData\Roaming
>>> Current directory = C:\myDirectory
>>> Running: git version
>>> Checking for a Subversion repository...
>>> Unable to execute "svn help": skipping SVN
>>> Checking for a Git repository...
>>> Running: git rev-parse --git-dir
>>> Running: git config core.bare
>>> Running: git rev-parse --show-toplevel
>>> Running: git symbolic-ref -q HEAD
>>> Running: git config --get branch.myBranchName.merge
>>> Command exited with rc 1: ['git', 'config', '--get',
u'branch.myBranchName.merge']
---
>>> Running: git config --get branch.myBranchName.remote
>>> Command exited with rc 1: ['git', 'config', '--get',
u'branch.myBranchName.remote']
---
>>> Running: git config --get remote.origin.url
>>> repository info: Path:
https://myUserName@myGitServer/bitbucket/scm/myRepository.git, Base path: ,
Supports changesets: False
>>> Making HTTP GET request to http://myReviewBoardServer/api/
>>> Running: git rev-parse refs/heads/myBranchName
>>> Running: git merge-base 71f1767180902f1cf6b3defbc8d5a9869576bf25
origin/myTrackingBranch
>>> Running: git rev-parse 2250f117eedb858afeaf824e2c45b22246a1d2fa
>>> Running: git status --porcelain --untracked-files=no
>>> Running: git rev-parse --git-dir
>>> Running: git -c core.quotepath=false -c diff.noprefix=false diff
--no-color --full-index --ignore-submodules -M --no-ext-diff
2250f117eedb858afeaf824e2c45b22246a1d2fa..71f1767180902f1cf6b3defbc8d5a9869576bf25
>>> Making HTTP GET request to
http://myReviewBoardServer/api/validation/diffs/
>>> Cached response for HTTP GET
http://myReviewBoardServer/api/validation/diffs/ expired and was modified
>>> Making HTTP POST request to
http://myReviewBoardServer/api/validation/diffs/
>>> Got API Error 224 (HTTP code 400): The specified diff file could not be
parsed.
>>> Error data: {u'stat': u'fail', u'reason': u'fatal: git cat-file: could
not get object info\n', u'err': {u'msg': u'The specified diff file could
not be parsed.', u'code': 224}}
Traceback (most recent call last):
File "C:/tools/RBTools/bin/../Python27/Scripts/rbt-script.py", line 8, in
load_entry_point('RBTools==0.7.4', 'console_scripts', 'rbt')()
File
"C:\tools\RBTools\Python27\lib\site-packages\rbtools-0.7.4-py2.7.egg\rbtools\commands\main.py",
line 133, in main
command.run_from_argv([RB_MAIN, command_name] + args)
File
"C:\tools\RBTools\Python27\lib\site-packages\rbtools-0.7.4-py2.7.egg\rbtools\commands\__init__.py",
line 612, in run_from_argv
exit_code = self.main(*args) or 0
File
"C:\tools\RBTools\Python27\lib\site-packages\rbtools-0.7.4-py2.7.egg\rbtools\commands\post.py",
line 754, in main
(msg_prefix, e))
rbtools.commands.CommandError: Error validating diff
The specified diff file could not be parsed. (HTTP 400, API Error 224)
Can anyone help with this error?
--
Supercharge your Review Board with Power Pack:
https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons:
https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
---
You received this message because you are subscribed to the Google Groups
"reviewboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to reviewboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
No horizontal scroll bar in review diffs
Running ReviewBoard v2.0.2, not getting horizontal scroll bars on review diffs page, though part of the diffs is off the right hand side of the page where not visible. I have tried using both Chrome Version 36.0.1985.143 m and IE Version 11.0.9600.17207, and no scroll bar in either. Is this a known bug? Greg -- Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/ --- Sign up for Review Board hosting at RBCommons: https://rbcommons.com/ --- Happy user? Let us know at http://www.reviewboard.org/users/ --- You received this message because you are subscribed to the Google Groups "reviewboard" group. To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
StarTeam integration?
Has anyone attempted StarTeam integration? Any rough guess as to the effort required to integrate to a repository implementation, specifically StarTeam? Thanks, Greg -- Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/ --- Sign up for Review Board hosting at RBCommons: https://rbcommons.com/ --- Happy user? Let us know at http://www.reviewboard.org/users/ --- You received this message because you are subscribed to the Google Groups "reviewboard" group. To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Warnings in server log
Thanks for the updates! 13:42:37 WARNING - /usr/local/lib/python2.7/dist-packages/Django-1.6.5-py2.7.egg/django/db/models/fields/__init__.py:848: RuntimeWarning: DateTimeField Review.timestamp received a naive datetime (2014-07-17 00:00:00) while time zone support is active. RuntimeWarning) I haven't seen this one. If you can figure out a reproduction case for this, it would be very helpful. I’ve seen this when moving from an older database (pre-Django 1.4), back when timezone information wasn’t included in the database. If this was a recent upgrade from 1.6 or older, I think this will happen. We are RB version 2.0.2. New install as a month ago. Not an upgrade. I'm not sure what action causes this warning. We get tons of these. Greg -- Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/ --- Sign up for Review Board hosting at RBCommons: https://rbcommons.com/ --- Happy user? Let us know at http://www.reviewboard.org/users/ --- You received this message because you are subscribed to the Google Groups "reviewboard" group. To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Warnings in server log
We just starting using ReviewBoard v2.0.2 integrated with git. We are seeing many instances of a few warnings in our server log. Is there maybe some configuration problem on our side that might be causing these warnings. Here are samples of the types of warnings we are seeing. We get many instances of each of these. I did some searches but did not find definitive explanations of these: 13:42:37 WARNING - /usr/local/lib/python2.7/dist-packages/Django-1.6.5-py2.7.egg/django/db/models/fields/__init__.py:848: RuntimeWarning: DateTimeField Review.timestamp received a naive datetime (2014-07-17 00:00:00) while time zone support is active. RuntimeWarning) 13:40:28 WARNING - Attempting to override delete count on FileDiffData 12a74691096148b5b997cfce58a970ad66a92bac from 0 to None (FileDiff None) 13:40:28 WARNING - Attempting to override insert count on FileDiffData 12a74691096148b5b997cfce58a970ad66a92bac from 4 to None (FileDiff None) Looks like maybe you guys have fixed these two already? 20:12:29 WARNING - Cache data for key "ourserver.com:8081:/:diffviewer/diff_file_fragment.html-24-3-1634-collapsed-highlighting-en-1407960566" (length 2103714) may be too big for the cache. 21:42:57 WARNING - /usr/local/lib/python2.7/dist-packages/ReviewBoard-2.0.2-py2.7.egg/reviewboard/diffviewer/diffutils.py:97: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal if diff.strip() == "": 13:47:59 WARNING - /usr/local/lib/python2.7/dist-packages/Django-1.6.5-py2.7.egg/django/http/response.py:327: DeprecationWarning: Using mimetype keyword argument is deprecated, use content_type instead super(HttpResponse, self).__init__(*args, **kwargs) 13:48:00 WARNING - /usr/local/lib/python2.7/dist-packages/feedparser-5.1.3-py2.7.egg/feedparser.py:364: DeprecationWarning: To avoid breaking existing software while fixing issue 310, a temporary mapping has been created from `updated_parsed` to `published_parsed` if `updated_parsed` doesn't exist. This fallback will be removed in a future version of feedparser. I would appreciate any feedback on any/all of these warnings. Maybe some/all these warnings are expected and can be ignored? Thanks, Greg -- Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/ --- Sign up for Review Board hosting at RBCommons: https://rbcommons.com/ --- Happy user? Let us know at http://www.reviewboard.org/users/ --- You received this message because you are subscribed to the Google Groups "reviewboard" group. To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: rbtools behavior with git branches
So I just tried this out. I believe TRACKING_BRANCH defaults to origin/ instead of origin/master as documented on the rbtools page. That would explain the behavior that we were seeing when we did not specify TRACKING_BRANCH. Pushing to the remote branch on origin caused there to be no diffs when creating the review. Now that I have added TRACKING_BRANCH = "origin/master" into our .reviewboardrc file, now the diffs are created fine. I also removed the BRANCH setting from .reviewboardrc. This only seems to change the "branch" value displayed in the review header area. Is there any other behavior associated with the BRANCH setting? Why can't rbtools determine the current git branch on its own? Greg On Tuesday, August 12, 2014 3:27:01 PM UTC-4, Christian Hammond wrote: > > Hi Greg, > > Which version of RBTools are you guys using? > > Try setting the following in .reviewboardrc: > > TRACKING_BRANCH = ‘origin/master’ > > That will ensure that, by default, rbt post will base commits off of > origin/master. > > The important thing is making sure that developers are actually using your > central repo as origin, and not their own clone. If their clone is named > origin, you’ll get that sort of behavior, requiring they override by doing > —tracking-branch=/master. > > I’d have to see more about their individual repo setups and their tree of > commits to really say for sure what’s happening, but that’s a good starting > point for diagnosing what’s wrong. > > Christian > > -- > Christian Hammond - chri...@beanbaginc.com > Review Board - http://www.reviewboard.org > Beanbag, Inc. - http://www.beanbaginc.com > > -- Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/ --- Sign up for Review Board hosting at RBCommons: https://rbcommons.com/ --- Happy user? Let us know at http://www.reviewboard.org/users/ --- You received this message because you are subscribed to the Google Groups "reviewboard" group. To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: rbtools behavior with git branches
Also, all devs use "origin" for the central repo. On Tuesday, August 12, 2014 3:58:42 PM UTC-4, Greg Burcher wrote: > > forgot to show our rbtools version: > > $ rbt --version > RBTools 0.6 > -- Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/ --- Sign up for Review Board hosting at RBCommons: https://rbcommons.com/ --- Happy user? Let us know at http://www.reviewboard.org/users/ --- You received this message because you are subscribed to the Google Groups "reviewboard" group. To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: rbtools behavior with git branches
forgot to show our rbtools version: $ rbt --version RBTools 0.6 -- Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/ --- Sign up for Review Board hosting at RBCommons: https://rbcommons.com/ --- Happy user? Let us know at http://www.reviewboard.org/users/ --- You received this message because you are subscribed to the Google Groups "reviewboard" group. To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: rbtools behavior with git branches
We had BRANCH = "master" in the .reviewboardrc, but no setting for TRACKING_BRANCH. The rbtools documentation says this: --tracking-branch <https://www.reviewboard.org/docs/rbtools/dev/rbt/commands/post/#cmdoption-rbt-post--tracking-branch> Tracking branch from which your branch is derived (git only, defaults to origin/master) The default can be set in TRACKING_BRANCH in .reviewboardrc. So the default value for TRACKING_BRANCH should already be "origin/master". I will make that change anyway. The docs say this about BRANCH: --branch <https://www.reviewboard.org/docs/rbtools/dev/rbt/commands/post/#cmdoption-rbt-post--branch> Affected branch. The default can be set in BRANCH in .reviewboardrc. What exactly does "Affected branch" mean? Maybe we should not be setting this value to "master"? We are almost always working in some branch off of master, not in master directly. Shouldn't rbtools be able to determine the current git branch in the local environment? What is the default behavior if we do not specify BRANCH in the .reviewboardrc file? Thanks, Greg On Tuesday, August 12, 2014 3:27:01 PM UTC-4, Christian Hammond wrote: > > Hi Greg, > > Which version of RBTools are you guys using? > > Try setting the following in .reviewboardrc: > > TRACKING_BRANCH = ‘origin/master’ > > That will ensure that, by default, rbt post will base commits off of > origin/master. > > The important thing is making sure that developers are actually using your > central repo as origin, and not their own clone. If their clone is named > origin, you’ll get that sort of behavior, requiring they override by doing > —tracking-branch=/master. > > I’d have to see more about their individual repo setups and their tree of > commits to really say for sure what’s happening, but that’s a good starting > point for diagnosing what’s wrong. > > Christian > > -- > Christian Hammond - chri...@beanbaginc.com > Review Board - http://www.reviewboard.org > Beanbag, Inc. - http://www.beanbaginc.com > > On August 12, 2014 at 10:54:40 AM, Greg Burcher (gregb...@gmail.com > ) wrote: > > Having read the available documentation regarding using rbtools and git, I > am still trying to understand how git reviews are working with our git > branching strategy. Some things are not working as we expect. > > We have a primary git repository origin/master. We have created a clone > repository of master on the server where ReviewBoard is installed, and this > repository is refreshed at intervals. All dev work is done on local > branches off of master, and then merged back into master. We create a > branch for each user story or defect that we work on. So the typical work > pattern looks like this: > > 1. Dev creates a local branch off of master. > 2. Dev makes changes in their local branch and commits. > 3. Dev uses "rbt post" to create a review. > 4. When review is complete, dev pushes branch to origin then merges to > master. > > This pattern works fine. From reading the rbtools docs, my understanding > is that "rbt post" diffs my local committed branch workspace against the > copy of master on the clone with the ReviewBoard server. > > If, instead, the dev pushes their branch to origin and then uses "rbt > post" to create a review, rbtools says there are no diffs. It is as if > rbtools is comparing the local copy of the branch to the origin copy of the > branch, or the same pushed commit level on the clone copy of master on the > ReviewBoard server, even though this branch is not yet merged to master. > > Also, some devs have suggested that they have seen diffs where it seems > rbtools is comparing their local branch to their local copy of the master > branch. > > Can someone explain the behavior of rbtools relative to git branches in > the branch/work strategy that I have described here? > > I think we are doing pre-commit reviews, since our branch is never merged > to master when we create the reviews. Even if we have pushed our branch to > origin, rbtools should be comparing against master and not our branch, > right? So this is not post-commit. > > To sum it up, we always want rbtools to compare the local committed branch > workspace to origin/master, or a clone of master local to the ReviewBoard > server. > > Thanks, > Greg > -- > Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/ > --- > Sign up for Review Board hosting at RBCommons: https://rbcommons.com/ > --- > Happy user? Let us know at http://www.reviewboard.org/users/ > --- > You received this message because you are subscribed to the Google Groups > "reviewboard" group. > To un
rbtools behavior with git branches
Having read the available documentation regarding using rbtools and git, I am still trying to understand how git reviews are working with our git branching strategy. Some things are not working as we expect. We have a primary git repository origin/master. We have created a clone repository of master on the server where ReviewBoard is installed, and this repository is refreshed at intervals. All dev work is done on local branches off of master, and then merged back into master. We create a branch for each user story or defect that we work on. So the typical work pattern looks like this: 1. Dev creates a local branch off of master. 2. Dev makes changes in their local branch and commits. 3. Dev uses "rbt post" to create a review. 4. When review is complete, dev pushes branch to origin then merges to master. This pattern works fine. From reading the rbtools docs, my understanding is that "rbt post" diffs my local committed branch workspace against the copy of master on the clone with the ReviewBoard server. If, instead, the dev pushes their branch to origin and then uses "rbt post" to create a review, rbtools says there are no diffs. It is as if rbtools is comparing the local copy of the branch to the origin copy of the branch, or the same pushed commit level on the clone copy of master on the ReviewBoard server, even though this branch is not yet merged to master. Also, some devs have suggested that they have seen diffs where it seems rbtools is comparing their local branch to their local copy of the master branch. Can someone explain the behavior of rbtools relative to git branches in the branch/work strategy that I have described here? I think we are doing pre-commit reviews, since our branch is never merged to master when we create the reviews. Even if we have pushed our branch to origin, rbtools should be comparing against master and not our branch, right? So this is not post-commit. To sum it up, we always want rbtools to compare the local committed branch workspace to origin/master, or a clone of master local to the ReviewBoard server. Thanks, Greg -- Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/ --- Sign up for Review Board hosting at RBCommons: https://rbcommons.com/ --- Happy user? Let us know at http://www.reviewboard.org/users/ --- You received this message because you are subscribed to the Google Groups "reviewboard" group. To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
