Hey James,
The problem really has to do with the limitations we're under when talking
to a Git repository. Let me go into that and then I'll go into how that
relates to what you're dealing with.
The reason that raw file URL field exists is because, with Git, it's not
possible to request a given file at a given SHA. You can clone the whole
repository, but that's not something Review Board can sanely do for every
change.
So, what we do instead is we build a URL, based off the mask provided, that
can give us the raw contents of a file, given a file path and a blob SHA1.
We need this so that we have a source file to apply a patch on top of.
Without that, we can't show a side-by-side diff.
Some services provide such a URL. GitWeb, for instance, has one. GitLab
does not. For GitLab, we have to instead query their API to get the data we
need. That requires such things as API tokens and other IDs, which Review
Board has special code to deal with, but that only works when selecting
GitLab as a hosting service.
Without either a selected (compatible) hosting service or a suitable Raw
File URL, we just have no ability to get the data needed in order to render
a change consistently.
If you have such a URL but without the field for the SHA, and you're only
ever dealing with reviewing changes on top of the very latest revision in
the repository, it will work, but that's going to fail the very moment
someone puts something up for review that is based on an older commit (and
this will happen in real usage all the time), or on top of a commit in a
branch other than 'master'.
Now, as for the analysis you've done, and the need for a third file, the
reason this is at all a problem is because you don't have the above setup,
so you're having to play games with your repository in a way that just
doesn't work.
If you did have such a setup, what you'd do is generate a diff between the
latest upstream commit and the commit just before the one you want to post
for review. That diff may cover a whole number of commits, but it doesn't
matter. That's the "parent diff." Once we fetch the proper source file from
the repository (using the hosting service or the raw file URL), we apply
the parent diff, and treat that as the base for the diff being reviewed.
Then, we apply the diff representing the commit(s) you want to actually
review.
RBTools takes care of all this automatically, letting you just do:
$ rbt post <mysha>
Christian
--
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
Beanbag, Inc. - http://www.beanbaginc.com
On Thu, Apr 23, 2015 at 4:16 PM, James Knight <james.d.kni...@live.com>
wrote:
> 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> 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.
>>> 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.
>
--
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.
