Re: rbtools behavior with git branches

[Matthew Woehlke]

On 2014-08-12 16:39, Greg Burcher wrote:
> 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?

(Rhetorical:) What does the 'branch' field in RB mean, anyway?

I have always taken it to be the intended merge target, which would be
'master' much of the time, but (heavily depending on the repository
workflow) not always. IMO RB does not presently have a proper notion of
'a symbolic name for this request via which it can be accessed given
some canonical remote'. (Which makes sense given RB's origin around the
svn era, but is something I'd really like to see added, if only for
reference purposes.)

Other sites may use the existing 'branch' field for that purpose. It
isn't really codified. Really, RB with git should have both; where you
want it merged to, and the symbolic name (if any) of the request. (And
also the SHA, if the code is at least locally committed, but I believe
2.x has that.)

Note that pre-commit is still a valid workflow; it's possible for
'target branch' to be meaningful and have more possible values than
'master' while 'local branch name' is empty / not applicable.

Given the above, I think it makes a lot of sense to have a default value
for target branch. I know that doesn't really help with your use case,
just trying to explain my take on why it works the way it does.

-- 
Matthew

-- 
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

[David Trowbridge]

The BRANCH/--branch settings just fill in the "Branch" field on the review
request.

-David


On Tue, Aug 12, 2014 at 12:57 PM, Greg Burcher 
wrote:

> We had BRANCH = "master" in the .reviewboardrc, but no setting for
> TRACKING_BRANCH. The rbtools documentation says this:
>
> --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
> 
>
> 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 unsubscribe from this group and stop receiving emails from it, send an
>> email to reviewboard...@googlegroups.c

Re: rbtools behavior with git branches

[Greg Burcher]

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

[Greg Burcher]

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

[Greg Burcher]

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

[Greg Burcher]

We had BRANCH = "master" in the .reviewboardrc, but no setting for 
TRACKING_BRANCH. The rbtools documentation says this:

--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 


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 unsubscribe from this group and stop receiving emails from it, send an 
> email to reviewboard...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
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 kn

Re: rbtools behavior with git branches

[Christian Hammond]

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 - christ...@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 (gregburc...@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 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.

-- 
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: TeamForge and Reviewboard

[Christian Hammond]

Hi Daniel,

Git has no ability to fetch individual file/revisions from a remote repository, 
so it’s not possible to just point to one. Instead, we have to either use a web 
front-end (like cgit, gitweb, or anything that provides an accessible URL 
fetching the raw file contents for a given path/SHA1), or a service’s API.

It looks like they may have such an API, but their docs on it are pretty bad. 
From looking through them, it doesn’t immediately look like it provides the 
(very basic) functionality we would need. For instance, I don’t see anything 
for getting the content of a file.

However, Gerrit does have an API, so it’s possible that support could be 
written to piggy-back on that and get the data we need. Unfortunately, it’s not 
flexible enough to be useable as the raw file URL, so explicit support in 
Review Board would need to be written.

That all being said, short of doing a paid development project, or someone 
volunteering a patch I won’t be able to get to this any time soon… Best bet 
right now is to see if TeamForge has any accessible URL for viewing the raw 
contents that takes a full SHA1 and a filename in the URL, and doesn’t require 
authentication to access it.

Christian

-- 
Christian Hammond - christ...@beanbaginc.com
Review Board - http://www.reviewboard.org
Beanbag, Inc. - http://www.beanbaginc.com

On August 12, 2014 at 5:51:22 AM, Daniel Laird (daniel.j.la...@googlemail.com) 
wrote:

All,

My company have a TeamForge service running and are using GIT as the default 
SCM.
I have a local Reviewboard server and would like to point it at the GIT repo - 
instead of using the default code review tool of gerrit

I am using Reviewboard 1.7.25 currently
The TeamForge project says that the clone URL is:
git clone ssh://MY_USERNAME@gerritforge.DOMAIN:PORT/dashboard

I have tried to setup a repo using my MY_USERNAME/PASSWORD, I have alos tried 
without.
But I am not having much luck.

Has anyone done this, or got it working or any ideas how I could get this 
working?

Many thanks
Dan
--
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.

-- 
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: Diff problems after 2.0.5 upgrade

[Christian Hammond]

Hey Andrew,

Can you check for JavaScript errors on their browsers?

Also, are these newly-uploaded diffs (since 2.0.5), or older ones?

Christian


On Tuesday, August 12, 2014, Andrew Hills (anhills) 
wrote:

> Hi all,
>
> After upgrading from 1.7.21 to 2.0.5, some users are reporting
> difficulties viewing diffs between diffs when one diff was uploaded prior
> to the upgrade, and the other after. Sometimes the page just never loads,
> and sometimes portions of the diffs are missing their content. Any
> suggestions?
>
> Thanks,
> Andrew
>
> --
> 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.
>


-- 
-- 
Christian Hammond - chip...@chipx86.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.

rbtools behavior with git branches

[Greg Burcher]

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.

Diff problems after 2.0.5 upgrade

[Andrew Hills (anhills)]

Hi all,

After upgrading from 1.7.21 to 2.0.5, some users are reporting difficulties 
viewing diffs between diffs when one diff was uploaded prior to the upgrade, 
and the other after. Sometimes the page just never loads, and sometimes 
portions of the diffs are missing their content. Any suggestions?

Thanks,
Andrew

-- 
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: Plugins for visual studio and eclipse

[Robert Munteanu]

The Eclipse plugin is https://github.com/rombert/ereviewboard . I'm still 
maintaining it, but I don't have a lot of time for it. Right now I'm 
looking to add support for the latest Eclipse versions, so any help is 
welcome :-)

Robert

On Monday, August 11, 2014 10:12:03 PM UTC+3, David Trowbridge wrote:
>
> At some point, someone made a plugin for eclipse. I don't know if it's 
> still maintained, or what the status of it is--it's not supported by the 
> review board project. I'm not aware of any visual studio plugins.
>
> -David
>
>
> On Mon, Aug 11, 2014 at 11:39 AM, Arjun A.M.  > wrote:
>
>>
>>
>> I am tying to research using reviewboard for my company and I was 
>> wondering if reviewboard has plugins for eclipse and visual studio. I know 
>> there is ereviewboard for eclipse. Is it a part of  the official 
>> reviewboard?
>>
>> Thanks
>> Arjun
>>
>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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: Review Board 2.0.5 released for EPEL 7

[Cian Mc Govern]

Thanks Stephen!

I've attempted to install this in the CentOS 7 Docker container and I hit
the following dependency issues:

Error: Package: ReviewBoard-2.0.5-1.el7.1.noarch (epel)
   Requires: httpd >= 2.4.7-5
   Available: httpd-2.4.6-17.el7.centos.1.x86_64 (base)
   httpd = 2.4.6-17.el7.centos.1
   Installing: httpd-2.4.6-18.el7.centos.x86_64 (updates)
   httpd = 2.4.6-18.el7.centos
Error: Package: ReviewBoard-2.0.5-1.el7.1.noarch (epel)
   Requires: httpd >= 2.4.7-5
   Available: httpd-2.4.6-17.el7.centos.1.x86_64 (base)
   httpd = 2.4.6-17.el7.centos.1
   Available: httpd-2.4.6-18.el7.centos.x86_64 (updates)
   httpd = 2.4.6-18.el7.centos
Error: Package: ReviewBoard-2.0.5-1.el7.1.noarch (epel)
   Requires: python-flup
Error: Package: ReviewBoard-2.0.5-1.el7.1.noarch (epel)
   Requires: python-pygments >= 1.6
   Available: python-pygments-1.4-9.el7.noarch (base)
   python-pygments = 1.4-9.el7

Any ideas?


On 8 August 2014 13:48, Stephen Gallagher  wrote:

> Hello folks! I just wanted to announce that as of a few minutes ago, I
> finally cleared the last hurdles to get Review Board 2.0.5 released into
> the EPEL 7 repository for Red Hat Enterprise Linux 7 (and derivatives,
> such as CentOS 7). It should filter out to the mirrors within a day or so.
>
> If you are interested in running Review Board 2.x on these platforms,
> please see instructions at
> https://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F
> to
> get the EPEL repository installed and then run "yum install ReviewBoard"
> to get the packages.
>
> Enjoy, and please give me feedback on how it works for you.
>
> --
> 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.
>

-- 
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: How can I post a review for selected files only?

[Tamer Afify]

Thanks David for the response. Upgrading to 0.6.2 fixed the issue for me.

On Wednesday, August 6, 2014 2:52:46 PM UTC-5, David Trowbridge wrote:
>
> Hi,
>
> There was a bug in 0.6 that prevented -I from working with SVN 
> repositories. This bug was fixed in 0.6.1
>
> -David
>
>
> On Wed, Aug 6, 2014 at 12:21 PM, Tamer Afify  > wrote:
>
>> Per the documentation this should do it for Server 1.7.22, rbt 0.6 and 
>> SVN repository
>> rbt post -I 
>> yet that generates a code review request (with a diff file) for all 
>> checked out files under current path (where rbt is called).
>>
>> Am I doing something wrong?
>>
>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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.

TeamForge and Reviewboard

[Daniel Laird]

All,

My company have a TeamForge service running and are using GIT as the 
default SCM.
I have a local Reviewboard server and would like to point it at the GIT 
repo - instead of using the default code review tool of gerrit

I am using Reviewboard 1.7.25 currently
The TeamForge project says that the clone URL is:
git clone ssh://MY_USERNAME@gerritforge.DOMAIN:PORT/dashboard

I have tried to setup a repo using my MY_USERNAME/PASSWORD, I have alos 
tried without.
But I am not having much luck.

Has anyone done this, or got it working or any ideas how I could get this 
working?

Many thanks
Dan

-- 
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: Clarification of Pre-Commit Workflow

[Kevan Stannard]

OK, thanks David.

Regards

Kevan


On Tuesday, 12 August 2014 09:22:55 UTC+10, David Trowbridge wrote:
>
> TRACKING_BRANCH should be set to something which is present in the 
> upstream copy of the repository that Review Board is talking to. In 
> general, it should be whichever branch you are looking to eventually merge 
> to.
>
> For example, in Review Board itself we have a .reviewboardrc which defines 
> TRACKING_BRANCH for each of our long-lived branches -- if one branches from 
> the release-2.0.x branch, TRACKING_BRANCH is set to origin/release-2.0.x, 
> or if branching from master, TRACKING_BRANCH is set to origin/master.
>
> -David
>
>
> On Thu, Aug 7, 2014 at 5:44 PM, Kevan Stannard  > wrote:
>
>> Many thanks Christian.
>>
>> If we're working in our own branch then what value should we use for 
>> TRACKING_BRANCH 
>> in .reviewboardrc?
>>
>> At the moment we've committed .reviewboardrc, but perhaps we should add 
>> it to git's ignore list and just set the TRACKING_BRANCH to our own 
>> working area branch?
>>
>> Thanks
>>
>>
>> On Thursday, 7 August 2014 06:53:56 UTC+10, Christian Hammond wrote:
>>
>>> Hi Kevan,
>>>
>>> That’s the workflow, though we strongly encourage you to post to a 
>>> branch based off master, and then only merge to master once it’s reviewed.
>>>
>>> rbt post will post from the upstream tracking branch (defaulting to 
>>> origin/master, customizable by TRACKING_BRANCH in .reviewboardrc or 
>>> —tracking-branch) to HEAD. In your case, it’s only posting the latest 
>>> commit because you’re committing to master, and have one change from 
>>> origin/master to there.
>>>
>>> If you set up Default Reviewers on Review Board, you won’t need to 
>>> choose any reviewers.
>>>
>>> Christian
>>>
>>> -- 
>>> Christian Hammond - chri...@beanbaginc.com
>>>
>>> Review Board - http://www.reviewboard.org
>>> Beanbag, Inc. - http://www.beanbaginc.com
>>>
>>> On August 5, 2014 at 10:42:45 PM, Kevan Stannard (kevans...@gmail.com) 
>>> wrote:
>>>
>>> I've been reading the workflow page here: 
>>> https://www.reviewboard.org/docs/manual/2.0/users/getting-
>>> started/workflow/
>>>  
>>> We're planning to follow the pre-commit workflow.
>>>
>>> Would be grateful if someone could clarify some of the steps for us. 
>>> Here's my current understanding of the first few steps:
>>>  
>>> *1) Make a change to your local source tree.*
>>>
>>> Here we:
>>> a) Edit a file
>>> b) Commit the change
>>>
>>>
>>> *2) Create a review request for your new change.*
>>>
>>>  Here we:
>>> a) Run rbt post (which seems to post the latest commit?)
>>>  
>>> *3) Publish the review request and wait for your reviewers to see it.*
>>>
>>> Here we:
>>> a) Log into Review Board
>>>  b) Choose reviewers
>>> c) Publish the review request
>>>  
>>>
>>>  At the moment we are all committing to master, then push to our origin 
>>> regularly.
>>>
>>> Thanks
>>>
>>>  
>>>  --
>>> 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...@googlegroups.com.
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>  -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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: unable to see the site after installation and configuration

[Stephen Gallagher]

On 08/11/2014 11:53 AM, Arjun s v wrote:
> Hi
> 
> I have followed the below steps to install the Reviewboard on fedora 14

WARNING, WARNING: Fedora 14?

This version of Fedora is very old (almost four years) and is both
unsupported and known to contain many security issues (it reached
end-of-life in December 2011). Furthermore, Fedora 20 has native
ReviewBoard 1.7.x packages. (And there are Fedora 21 and RHEL/CentOS 7
packages for the 2.0.x series). You should *really* upgrade.


> 
> 
> Installing Python Setuptools
> # yum install python-setuptools
> # easy_install -U setuptools
> 
> Installing Python Develoopment Headers
> # yum install python-devel
> 
> Installing memcached
> # rpm -Uvh
> http://mirrors.kernel.org/fedora-epel/5/x86_64/epel-release-5-4.noarch.rpm
> # yum install memcached
> # easy_install python-memcached
> 

Mixing EPEL packages with Fedora packages is begging for trouble.


> Installing Patch
> # yum install patch
> 
> Installing Review Board
> # easy_install ReviewBoard
> Wait until you see the message "Finished processing dependencies for
> ReviewBoard".
> 
> Installing Database Bindings
> # yum install MySQL-python
> # easy_install mysql-python
> 
> Installing Source Control Components
> # yum install cvs
> # yum install git-core
> # yum install subversion
> # yum install pysvn
> 
> Mercurial
> # easy_install mercurial
> 
> Perforce
> # easy_install P4PythonInstaller
> 
> Installing Amazon S3 Support
> # easy_install django-storages
> 
> Installing Development Tools
> # easy_install nose Sphinx
> 
> Creating Database
> # mysql -uroot -h127.0.0.1 -P3306 -p
>> create database reviewboard;
>> GRANT ALL PRIVILEGES ON reviewboard.* TO 'reviewboard'@'127.0.0.1'
> identified by 'reviewboard';
>> GRANT ALL PRIVILEGES ON reviewboard.* TO 'reviewboard'@'127.0.0.1'
> identified by 'reviewboard';
> 
> Creating a Review Board Site
> # rb-site install /var/www/reviewboard
> 
> - Domain Name: reviews.rocfm.com
> - Root Path [/]: /reviews/
> - Media URL [media/]: media/
> - Database Type: mysql
> - Database Name [reviewboard]: reviewboard
> - Database Server [localhost]: 127.0.0.1
> - Database Username: reviewboard
> - Database Password: reviewboard
> - Cache Type: memcached
> - Memcache Server [memcached://localhost:11211/]:
> memcached://localhost:11211/
> - Web Server: apache
> - Python Loader: wsgi
> - Username [admin]: admin
> - Password: admin
> - E-Mail Address: x...@gmail.com
> 
> Then you will see:
> ---
> * The site has been installed
> 
> The site has been installed in /var/www/reviewboard
> 
> Sample configuration files for web servers and cron are available
> in the conf/ directory.
> 
> You need to modify the ownership of the following directories and
> their contents to be owned by the web server:
> * /var/www/reviewboard/htdocs/media/uploaded
> * /var/www/reviewboard/data
> 
> For more information, visit:
> 
> http://www.reviewboard.org/docs/manual/dev/admin/sites/creating-
> sites/
> ---
> 
> Configuring Apache
> # yum install mod_wsgi
> # chown -R apache:apache /var/www/reviewboard/
> # cp /var/www/reviewboard/conf/apache-wsgi.conf /etc/httpd/conf.d/
> 
> # vim /etc/httpd/conf/httpd.conf
> Add the follow item:
> ---
> LoadModule wsgi_module modules/mod_wsgi.so
> 
> # vim /etc/httpd/conf.d/apache-wsgi.conf
> Change the port into 8080:
> ---
> 
> 
> # /etc/init.d/httpd restart
> 
> after this if i type reviews.rocfm.com:8080/reviews/ in browser i m not
> getting ,so provide me help to get the site up and also me help how to
> download the source code and install it instead of using yum installation
> 
> Thanks in advance  for the help
> 
> -- 
> 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.

-- 
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: Permission denied accessing the local Git repository '/home/user/foo/.git'

[julian . jacobson]

I have the same problem on Ubuntu 12.04. All the rest works really well, 
but I still get the same error message when trying to add local git 
repositories.
Has anyone managed to do this successfully?

-- 
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.