Hi Joe,
Yeah, you'd have to set the content type. That's one of the reason we ended
up moving to the new model, so that we can more easily send the headers we
need and process the resulting data.
Glad it's working now!
Christian
--
Christian Hammond - chip...@chipx86.com
Review Board - http://
Christian,
Thanks for clearing up the mystery.
We went back to the v2 api whose raw URLs look like:
/api/v2/yaml/blob/show/cm/ultrasound/?login=...&token=...
As near as I can tell, the equivalent v3 url would be
/api/v3/repos/cm/ultrasound/git/blobs/?access_token=...
but the default content type
Is the simple diff adding a new file? In that case, it wouldn't need to
touch the repo.
Christian
--
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com
On Fri, Oct 5, 2012 at 1:48 PM, Joe wrote:
> Christian,
>
> Actually I'm
Christian,
Actually I'm sure going back to the old raw-file URL will work -- we did
some tests -- but like the GitHub service, the latest version of the
self-hosted GitHub also drops the v2 api and requires the username/password
pair.
The part that confuses me, is that a simple diff works, but
Hi Joe,
GitHub itself moved to requiring the new API several months back, and for
that, we had to introduce deeper hosting service support. In order to talk
to github.com, Hosting Service must be set to GitHub.
Now, for a self-hosted GitHub instance, I imagine the old API still exists.
In that ca
Hi,
We upgraded to 1.6.12 from 1.6.3 yesterday. We're using an internal github
as our master repository, and have about 20 repositories defined in
reviewboard. The hosting service is set to None, the type to git, the paths
look
like g...@github.corp.ad.local:cm/transform.git. For the upgrade we
