Re: Confirming Git pre-commit workflow

[Christian Hammond]

Hi Mathias,

That process looks right, but you shouldn't get that error if the
repository configuration in Review Board is correct. Can you show me what
that looks like?

Christian

On Wed, Jan 24, 2018 at 1:27 AM, Mathias Sulser  wrote:

> Hi,
>
> I am new to reviewboard and currently debugging my setup. I wanted to
> confirm the “git pre-commit review” workflow:
>
> 1/ Clone the central repository
> 2/ Make a change to file X, and commit it to a local branch
> 3/ Run rbt post
> 4/ ..
>
> Should I now get an error saying file X was not found at rev xyz, this
> would imply a setup error I assume. Or is it possible that I misunderstood
> how pre-commit reviews should work?
>
> Cheers, Mathias
>
> --
> 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
> "Review Board Community" 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
President/CEO of Beanbag 
Makers of Review Board 

-- 
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 
"Review Board Community" 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.

Confirming Git pre-commit workflow

[Mathias Sulser]

Hi,

I am new to reviewboard and currently debugging my setup. I wanted to confirm 
the “git pre-commit review” workflow:

1/ Clone the central repository
2/ Make a change to file X, and commit it to a local branch
3/ Run rbt post
4/ ..

Should I now get an error saying file X was not found at rev xyz, this would 
imply a setup error I assume. Or is it possible that I misunderstood how 
pre-commit reviews should work?

Cheers, Mathias

-- 
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 
"Review Board Community" 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: Clarification of Pre-Commit Workflow

[David Trowbridge]

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

[Kevan Stannard]

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clarification of Pre-Commit Workflow

[Christian Hammond]

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

Clarification of Pre-Commit Workflow

[Kevan Stannard]

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pre-Commit Workflow

[Charles Yates]

Guess it might be easier if I provide the script and associated document 
which I'm muttering about here :).

https://docs.google.com/document/d/1z3XtAsVoCx9BDWS8itFZ0mOTd9d66tPus7eSE13m0eM

It's very much a prototype - just knocked up in handful of shell scripts 
(I've only included a couple of the more stable ones at the moment in the 
Appendices - will post a couple more down the line... maybe). I may 
re-implement in python and extend beyond the bzr only support at some point 
(providing other people find it useful or another approach isn't found).

AFAICT, it should be sufficient to replace bzr with svn throughout to have 
support there, but I haven't tested this. 

--diff and --overlap require interdiff from patchutils - if you don't have 
them installed, it should gracefully die should you attempt to use those 
switches. 

It could be greatly enhanced by the use of the reviewboard web api, but 
this was considered overkill and too painful for bash :).

All very hokey and incomplete, but functional enough to meet my 
requirements.

-- 
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/groups/opt_out.

Re: Pre-Commit Workflow

[Christian Hammond]

On Wed, Feb 19, 2014 at 7:36 AM, Allen  wrote:

> I have no idea why the review board changes the paths from local to remote
> server, at least it should keep the local working copy`s path.
>
> Here`s a example of what those paths look like:
>
> --- /trunk/ReviewBoardTest/src/ReviewBoardTest.java   (revision 166)
> +++ /trunk/ReviewBoardTest/src/ReviewBoardTest.java   (working copy) you 
> see here? The working copy is locally, but the review board still changes its 
> path to remote server.
>
>
Just to keep this from becoming a confusing point of discussion in this
thread..

This is normal for an SVN diff. It's just a diff relative to the root of
the repo, and not a remote path of any sort. This is what patch -p is made
for.

There's another thread already open for this, but for followers of this
thread, I don't want people to get the wrong idea about anything and get
stuck on this point.

Christian

-- 
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/groups/opt_out.

Re: Pre-Commit Workflow

[Charles Yates]

On Wednesday, 19 February 2014 21:15:31 UTC+1, David Trowbridge wrote:
>
> The typical way that other dvcs users do this is to have local branches 
> for each piece of work, and post from each of those. I don't know enough 
> about bzr's workflow to know if that would be appropriate (though I recall 
> bzr branches being pretty heavyweight).
>

Heh - well, in our case, the actual checkout itself is rather minor in the 
grand scheme of things - the compiled code is over a 1GB per build, so I 
tend to avoid having multiple checkouts where possible. Multiple builds 
also screw up my usage of ccache which does greatly help... providing I'm 
rebuilding incremental changes in the same checkout. As soon as I'm using 
multiple build directories, clean builds tend to get a lot slower.

 Cheers,

Charlie

-- 
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/groups/opt_out.

Re: Pre-Commit Workflow

[Charles Yates]

On Wednesday, 19 February 2014 16:36:21 UTC+1, Allen wrote:
>
> Really good question! 
> I also encounter the same problem. Developers dont want to wait until the 
> previous review passed to work on the next issue. 
> One solution I think is, once a review passed, apply that review`s patch 
> file to a new working copy without touching what you are currently working 
> on, then commit it. After the commit is done, you can keep going.
>

With the script I use, I tend to work with a single checkout. There's a 
little bit of manual cherry picking when I initially create the first 
reviewboard post, but subsequently, it remembers which files are associated 
to the , so the workflow goes something like:

* I create a new reviewboard entry via the website (I find this easier for 
adding detailed descriptions, test information and assigning to another 
developer). 

* After that point, I use the script to create and upload the diff like:

post  --new file1 file2 ..

or entire subdirectories or other file patterns (non specification of files 
takes all currently modified files). This uploads the current diffs in 
those files to the review id (there's also a --publish switch but I tend to 
do a sanity check in the browser to check on whitespace, mismatching 
indents and so on).

* Once done, and pre-review, I start working on the another patch and 
repeat the process - cherry picking the files which are involved in that 
review (this essentially disallows subsequent jobs from overlapping with 
the files in the first review, though there is an attempt to provide some 
support for that - typically, I see such tasks as blocking ones and insist 
on the prior review being carried out first).

* During the review process, I tend to make the modifications for the id's 
as per the review of my colleague, and run:

post 

after making the suggested modifications - this just uploads the revised 
patch for the files associated to that review id (being a no-op if no 
subsequent changes have occurred).

* At the point of checkin, I tend to use:

bzr ci -m "blah" `post  --list`

And this commits the changes for that id, leaving everything else alone.

There are few other odds and ends in the script (and scripts which use that 
one :)) which assist in associating (and disassociating) files from reviews 
and that provide a view of changes since the last post (post  --diff 
for example).

None of it's ideal as it's not entirely automated (and the overlapping file 
restrictions kinda hurts), but it works fairly well and at the very least 
doesn't need me to cherry pick the file list on every subsequent post, 
diff, checkin etc.

 

> But the pinpoint is, when you create a code review, the paths in the patch 
> file is NOT your local path but some paths in the SVN server(I am using 
> SVN). That prevents me to apply patches(wrong patch error). 
> I have no idea why the review board changes the paths from local to remote 
> server, at least it should keep the local working copy`s path.
>
> Here`s a example of what those paths look like:
>
> --- /trunk/ReviewBoardTest/src/ReviewBoardTest.java   (revision 166)
> +++ /trunk/ReviewBoardTest/src/ReviewBoardTest.java   (working copy) you 
> see here? The working copy is locally, but the review board still changes its 
> path to remote server.
>
>
Ah - that's interesting - I tend to pull other developers patches from the 
reviewboard when I'm reviewing them using:

rbt patch  --print | patch -p0

and those apply to my checkouts correctly (assuming compatible branches and 
lack of conflicts in local mods). I tend to use a second checkout when 
reviewing the work of others, and resolve conflicts in my own main checkout 
after those have been committed (invoking post  for each of my pending 
reviews). 

The pulled patches don't have the branch reflected in the paths though - 
guess this could be an svn specific thing? Perhaps patch -p1 would resolve 
that specific issue for you?

Cheers,

Charlie




-- 
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/groups/opt_out.

Re: Pre-Commit Workflow

[David Trowbridge]

The typical way that other dvcs users do this is to have local branches for 
each piece of work, and post from each of those. I don't know enough about 
bzr's workflow to know if that would be appropriate (though I recall bzr 
branches being pretty heavyweight).

-David

> On Feb 15, 2014, at 12:51 PM, Charles Yates  wrote:
> 
> Hi,
> 
> We're trying to follow a pre-commit workflow with bzr with all patches 
> submitted to the review board prior to checkin to the repo - I was wondering 
> anyone had any experience with this and how best to handle pending patches. 
> 
> Sometimes it's inconvenient to wait for the review process to be completed 
> before working on another part of the code - as a result, I can have a few 
> patches pending and cherry picking the right files from the checkout to 
> manually create a diff can be quite time consuming and error prone when there 
> are a handful of small review posts pending. 
> 
> I've written a quick and dirty script which associates specific files with a 
> review ticket and provides me with a view of changes which have been made on 
> those files since the last posting - it also allows the files included to be 
> manipulated from the command line and post the current patches as required. 
> I'm quite sure it can be improved upon and would be happy to provide a link 
> to it if anyone is curious (or just wants to point and laugh :p). 
> 
> I was wondering if there were other ways to handle this - I was vaguely 
> thinking about using some kind of local repo, tagging each checkin comment 
> with the associated review id and creating review posts from that, but it 
> would still involve some kind of manual cherry picking process when handling 
> merges from other developers. With the tool I have, the latter tends to be a 
> bit of a non-issue as I just need to make the corrections, and run my script 
> against each of my pending reviews and it does the rest (with the exception 
> of patches which pending patches which touch the same source files - those 
> tend to block me until the previous review is cleared up).
> 
> Possibly over thinking the issue :-) - any suggestions welcome.
> 
> Cheers,
> 
> Charlie
> -- 
> 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/groups/opt_out.

-- 
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/groups/opt_out.

Re: Pre-Commit Workflow

[Allen]

Really good question! 
I also encounter the same problem. Developers dont want to wait until the 
previous review passed to work on the next issue. 
One solution I think is, once a review passed, apply that review`s patch 
file to a new working copy without touching what you are currently working 
on, then commit it. After the commit is done, you can keep going.
But the pinpoint is, when you create a code review, the paths in the patch 
file is NOT your local path but some paths in the SVN server(I am using 
SVN). That prevents me to apply patches(wrong patch error). 
I have no idea why the review board changes the paths from local to remote 
server, at least it should keep the local working copy`s path.

Here`s a example of what those paths look like:

--- /trunk/ReviewBoardTest/src/ReviewBoardTest.java (revision 166)
+++ /trunk/ReviewBoardTest/src/ReviewBoardTest.java (working copy) you 
see here? The working copy is locally, but the review board still changes its 
path to remote server.

-- 
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/groups/opt_out.

Pre-Commit Workflow

[Charles Yates]

Hi,

We're trying to follow a pre-commit workflow with bzr with all patches 
submitted to the review board prior to checkin to the repo - I was 
wondering anyone had any experience with this and how best to handle 
pending patches. 

Sometimes it's inconvenient to wait for the review process to be completed 
before working on another part of the code - as a result, I can have a few 
patches pending and cherry picking the right files from the checkout to 
manually create a diff can be quite time consuming and error prone when 
there are a handful of small review posts pending. 

I've written a quick and dirty script which associates specific files with 
a review ticket and provides me with a view of changes which have been made 
on those files since the last posting - it also allows the files included 
to be manipulated from the command line and post the current patches as 
required. I'm quite sure it can be improved upon and would be happy to 
provide a link to it if anyone is curious (or just wants to point and laugh 
:p). 

I was wondering if there were other ways to handle this - I was vaguely 
thinking about using some kind of local repo, tagging each checkin comment 
with the associated review id and creating review posts from that, but it 
would still involve some kind of manual cherry picking process when 
handling merges from other developers. With the tool I have, the latter 
tends to be a bit of a non-issue as I just need to make the corrections, 
and run my script against each of my pending reviews and it does the rest 
(with the exception of patches which pending patches which touch the same 
source files - those tend to block me until the previous review is cleared 
up).

Possibly over thinking the issue :-) - any suggestions welcome.

Cheers,

Charlie

-- 
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/groups/opt_out.

Re: pre-commit workflow

[Jeff Andros]

it runs on your developer's boxes... here's documentation:
http://code.google.com/docreader/#p=reviewboard&s=reviewboard&t=Using_PostReview

I guess you could run it on a box with SSH, but that seems overkill



2009/2/13 Brot :
>
> Is there any documentation for this post-review script?
> Where should this script run? In my case we are using a linux server
> for review-board and have windows-client where we are working on our
> code (svn working base is on windows). Does this script fit into this
> environment?
> Do I have the possibility to connect via ssh and work with the post-
> review script?
>
> Another alternative could be a REST webservice for review-board to
> upload new reviews?!
>
> ~ Bernd
>
>
> On 12 Feb., 18:26, Jeff Andros  wrote:
>> 2009/2/12 Brot 
>>
>>
>>
>> > Hello,
>>
>> > today I installed Reviewboard and now I have a few questions.
>>
>> > 1)
>> > Is there a possibility to create reviews from the command-line or in
>> > scripts? It's not really handy to upload the diff-file for every
>> > review. The manual way wouldn't get acceptance and the developers will
>> > not use reviews.
>>
>> Yup! there's a script called post-review... I think for now you have to get
>> it from SVN, but Christian is working on packaging this for easy_install
>>
>>
>>
>> > 2)
>> > If a developer accepts an review, is there a way to commit the
>> > reviewed diff automatically?
>>
>> Not by default... that's a job for your SCM...although the forthcoming
>> extensions might make that possible... or you might be able to use the API
>> to have a daemon search for shipit tags and submit for you
>>
>>
>>
>> > ~ Bernd
>>
>> --
>> Jeff
>> O|||O
> >
>



-- 
Jeff
O|||O

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

Re: pre-commit workflow

[Brot]

Is there any documentation for this post-review script?
Where should this script run? In my case we are using a linux server
for review-board and have windows-client where we are working on our
code (svn working base is on windows). Does this script fit into this
environment?
Do I have the possibility to connect via ssh and work with the post-
review script?

Another alternative could be a REST webservice for review-board to
upload new reviews?!

~ Bernd


On 12 Feb., 18:26, Jeff Andros  wrote:
> 2009/2/12 Brot 
>
>
>
> > Hello,
>
> > today I installed Reviewboard and now I have a few questions.
>
> > 1)
> > Is there a possibility to create reviews from the command-line or in
> > scripts? It's not really handy to upload the diff-file for every
> > review. The manual way wouldn't get acceptance and the developers will
> > not use reviews.
>
> Yup! there's a script called post-review... I think for now you have to get
> it from SVN, but Christian is working on packaging this for easy_install
>
>
>
> > 2)
> > If a developer accepts an review, is there a way to commit the
> > reviewed diff automatically?
>
> Not by default... that's a job for your SCM...although the forthcoming
> extensions might make that possible... or you might be able to use the API
> to have a daemon search for shipit tags and submit for you
>
>
>
> > ~ Bernd
>
> --
> Jeff
> O|||O
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: pre-commit workflow

[Jeff Andros]

2009/2/12 Brot 

>
> Hello,
>
> today I installed Reviewboard and now I have a few questions.
>
> 1)
> Is there a possibility to create reviews from the command-line or in
> scripts? It's not really handy to upload the diff-file for every
> review. The manual way wouldn't get acceptance and the developers will
> not use reviews.


Yup! there's a script called post-review... I think for now you have to get
it from SVN, but Christian is working on packaging this for easy_install

>
>
> 2)
> If a developer accepts an review, is there a way to commit the
> reviewed diff automatically?
>
Not by default... that's a job for your SCM...although the forthcoming
extensions might make that possible... or you might be able to use the API
to have a daemon search for shipit tags and submit for you

>
>
> ~ Bernd
>
>
>
> >
>


-- 
Jeff
O|||O

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

pre-commit workflow

[Brot]

Hello,

today I installed Reviewboard and now I have a few questions.

1)
Is there a possibility to create reviews from the command-line or in
scripts? It's not really handy to upload the diff-file for every
review. The manual way wouldn't get acceptance and the developers will
not use reviews.

2)
If a developer accepts an review, is there a way to commit the
reviewed diff automatically?


~ Bernd



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