Sorry, I don't understand.

My root patch has an addressable hash from the repository. When I initially 
showed the following diagram, the intent was to show that my local and 
ReviewBoard-watched remote repository are in sync.

                   {ReviewBoard}
                     /\
                     ||
                     \/
     {Local}      {Remote}
     
     Commit F      Commit F
        |             |
     Commit E      Commit E

If I then make a commit in my local repository, generate a patch, I can 
submit it successfully to ReviewBoard since all file indexes are 
addressable:

    /- (patch) ->  {ReviewBoard}
   /                 /\
  /                  ||
  |                  \/
   \ {Local}      {Remote}
    \  
     Commit 1
        |
     Commit F      Commit F
        |             |
     Commit E      Commit E

The patch changes to existing file indexes will all exist in Commit F 
(which ReviewBoard can handle) and any new files will have a zeroed-file 
index. If I introduce a new file in commit 1, I'll have an entry in my diff 
as follows:

diff --git a/newfile b/newfile
new file mode 100644
index 
0000000000000000000000000000000000000000..E0C9035898DD52FC65C41454CEC9C4D2611BFB37
--- /dev/null
+++ b/newfile

Now, if I have a second commit which modifies the file 
(E0C9035898DD52FC65C41454CEC9C4D2611BFB37) I've introduced in Commit 1, 
ReviewBoard will not accept the patch since it cannot find the 
E0C9035898DD52FC65C41454CEC9C4D2611BFB37 object.

    /- (patch) ->  {ReviewBoard}    <-- Will fail.
   /                 /\
  /                  ||
  |                  \/
   \ {Local}      {Remote}
    \  
     Commit 2
        |
     Commit 1
        |
     Commit F      Commit F
        |             |
     Commit E      Commit E

Luckily, ReviewBoard supports uploading parent DIFF's so I can bridge the 
gap. By uploading my Commit 2 DIFF with a parent Commit 1 DIFF, ReviewBoard 
accepts the patch with no issues. I assume that this is the case since 
ReviewBoard has a list of all file indexes from Commit F and an overlay of 
file indexes from the parent DIFF provided. Therefore, if my Commit 2 has 
the following:

diff --git a/newfile b/newfile
new file mode 100644
index 
E0C9035898DD52FC65C41454CEC9C4D2611BFB37..7E240DE74FB1ED08FA08D38063F6A6A91462A815
+++ a/newfile
+++ b/newfile

ReviewBoard can establish following:

    0000000000000000000000000000000000000000 <- 
E0C9035898DD52FC65C41454CEC9C4D2611BFB37 <- 
7E240DE74FB1ED08FA08D38063F6A6A91462A815

And the following will work:

    /--- (parent patch) \
   /                    \/
  / /- (patch) ->  {ReviewBoard}    <-- Will work.
 / /                 /\
/ /                  ||
| |                  \/
|  \ {Local}      {Remote}
 \  \  
  \  Commit 2
   \    |
     Commit 1
        |
     Commit F      Commit F
        |             |
     Commit E      Commit E

This leads back to the initial question. If I had a third commit (or more), 
how can I get ReviewBoard to interpret the changes? From what it looks 
like, it doesn't seem possible. For example, if Commit 3 had the following:

diff --git a/newfile b/newfile
new file mode 100644
index 
7E240DE74FB1ED08FA08D38063F6A6A91462A815..70C881D4A26984DDCE795F6F71817C9CF4480E79
+++ a/newfile
+++ b/newfile

There is no means which I can provide all three (3) DIFFs to ReviewBoard to 
establish this chain:

    0000000000000000000000000000000000000000 <- 
E0C9035898DD52FC65C41454CEC9C4D2611BFB37 <- 
7E240DE74FB1ED08FA08D38063F6A6A91462A815 <- 
70C881D4A26984DDCE795F6F71817C9CF4480E79

I don't know how to explain it more than that. :(

On Thursday, April 23, 2015 at 6:09:41 PM UTC-4, Stephen Gallagher wrote:
>
> You're missing the point though. You still have to have an addressable 
> hash from the repo in order to establish a baseline or else none of the 
> parent diffs will have anything to compare against.
> On Thu, Apr 23, 2015 at 5:23 PM James Knight <james.d...@live.com 
> <javascript:>> wrote:
>
>> First of all, thanks for the replies; I appreciate the help.
>>
>> @Stephen Gallagher
>> I think this is were I am failing to communicate. I'm not trying to have 
>> my Git repository or web viewer to represent the file hashes as I haven't 
>> pushed anything to a remote Git repository. I'm hoping to avoid this by 
>> providing raw patches with full Git indexes to fill in the gap.
>>
>> I'm going off the concept I see here 
>> <https://www.reviewboard.org/docs/manual/2.0/webapi/2.0/resources/diff-list/>
>> .
>>
>> A parent diff can be uploaded along with the main diff. A parent diff is 
>>> a diff based on an existing commit in the repository, which will be applied 
>>> before the main diff. The parent diff will not be included in the diff 
>>> viewer. It’s useful when developing a change based on a branch that is not 
>>> yet committed. In this case, a parent diff of the parent branch would be 
>>> provided along with the diff of the new commit, and only the new commit 
>>> will be shown.
>>>
>>
>> I'm assuming that ReviewBoard just doesn't support multiple parent diffs. 
>> My current work around is to squash the series of parent commits for a 
>> given patch and add rebase my commits off their respective squashed 
>> parents. This will provide me with both my diff to review and a parent diff 
>> that I can submit to ReviewBoard. For example:
>>
>>      {Local}
>>
>>      Commit 4
>>         |
>>      Commit 3
>>         |
>>      Commit 2      Commit 3b           Commit 4b
>>         |             |                   |
>>      Commit 1   Squash Commit 1-2   Squash Commit 1-3
>>         |             |                   |
>>         |-------------|--------------------
>>         |
>>      Commit F
>>         |
>>      Commit E
>>
>>
>>    - 
>>    - Make review 1 with `Commit 1` patch.
>>    - Make review 2 with `Commit 2` patch with parent `Commit 1` patch.
>>    - Make review 3 with `Commit 3b` patch with parent `Squash Commit 
>>    1-2` patch.
>>    - Make review 4 with `Commit 4b` patch with parent `Squash Commit 
>>    1-3` patch.
>>
>> Again, I know this isn't ideal but it works for now.
>>
>> @David Trowbridge
>>
>> I can't use the GitLab optional since it requires (to my knowledge) it's 
>> either for online GitLab hosting (which it not what I'm using; using a 
>> local GitLab CE installation) or requires an account setup on the GitLab 
>> server (which again, will not for us since we use LDAP and favor deployment 
>> keys). Unless there's another option I'm missing?
>>
>>
>> On Thursday, April 23, 2015 at 4:03:59 PM UTC-4, David Trowbridge wrote:
>>
>>> Yeah, the raw file URL needs to have the revision in there somewhere. 
>>> Since you're using GitLab, you should just choose "GitLab" instead of "None 
>>> - Custom Repository"
>>>
>>> -David
>>>
>>> On Thu, Apr 23, 2015 at 10:52 AM Stephen Gallagher <
>>> ste...@gallagherhome.com> wrote:
>>>
>>>> On Thu, Apr 23, 2015 at 11:49 AM James Knight <james.d...@live.com> 
>>>> wrote:
>>>>
>>>>> Repository options are configured as follows:
>>>>>
>>>>>    - Hosting Service: None - Custom Repository
>>>>>    - Repository Type: Git
>>>>>    - Path: git@myserver:mygroup/myproject.git
>>>>>    - Raw file URL mask: http://myserver/mygroup/myproject/raw/develop/
>>>>>    <filename>
>>>>>
>>>>>
>>>> This isn't going to work if you don't have a way to represent the 
>>>> individual file hashes. That's why it can't find them to compare. What 
>>>> tool 
>>>> are you using to view the files via the web? Generally, cgit and gitweb 
>>>> work best.
>>>>
>>>> -- 
>>>> 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...@googlegroups.com.
>>>
>>>
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>  -- 
>> 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...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

Reply via email to