Ah, completely understand now. Sorry for the trouble folks. Thanks Christian (and of course David and Stephen as well).
On Thursday, April 23, 2015 at 8:22:42 PM UTC-4, Christian Hammond wrote: > > 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 - [email protected] <javascript:> > Review Board - http://www.reviewboard.org > Beanbag, Inc. - http://www.beanbaginc.com > > On Thu, Apr 23, 2015 at 4:16 PM, James Knight <[email protected] > <javascript:>> 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 <[email protected]> >>> 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 < >>>>> [email protected]> wrote: >>>>> >>>>>> On Thu, Apr 23, 2015 at 11:49 AM James Knight <[email protected]> >>>>>> 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 [email protected]. >>>>> >>>>> >>>>>> 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 [email protected]. >>>> 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 [email protected] <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 [email protected]. For more options, visit https://groups.google.com/d/optout.
