Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 3277 by Different URLs for same SVN repository no longer working

What version are you running?

RBTools 0.5.0

What's the URL of the page containing the problem?


What steps will reproduce the problem?

1. Create web accessible (SSL) SVN repository on the the local host.
2. In reviewboard admin, create a repository object for the new SVN repository with with using the SSL url path -- https://... 3. invoke post-review (or "rbt post") in the SVN post-review script with option repository_url set to the local path to the repository -- file:///...
4. Perform and SVN commit on the local host.

What is the expected output? What do you see instead?

We expect a new review request to be created in reviewboard. Instead we get a webapi error because the local SVN url does not designate a reviewboard host.

What operating system are you using? What browser?
Gentoo Linux 3.8.13; Firefox

Please provide any additional information below.


We configure our repostitories in ReviewBoard with URL's of the form  In our SVN post-commit hook
script we invoke the ,now deprecated, post-review command supplying
"file:///locapath/repo_name" to the repository_url option.

I propose adding a "repository-webapi-url" option to supplement the
"repository-url" option to the rbt post command to support this
formerly supported use case.


Up until a code change about 3 years ago: ยป jankoprowski
2011-04-03 [RBTools] Brand new Clear Case implementation

RBTools supported the use case decribed above. Subsequently (at
least as of RBTools 0.5.0) we have continued to support our usage by
simply removing the first option in the following assignment in the
new_review_request function in

    repository = options.repository_url or

We are now trying to upgrade to RBTools 0.5.7 and in the processing
changing to using "rbt post" instead of the deprecated
post-review. Our simple patch is no longer sufficient.

It appers the underlying mechanism that was support our usage--
SVBClient:find_server_repository_info--is still present in 0.5.7, So
with a slightly more involved patch, we could probably carry on as
before. But we would prefer, of course, that we not need to patch
every upgrade. Unless there is actual opposition to supporting our use
case, can this be addressed?

Being unable to distinguish between what might be oversight, design
evolution, or just thick-headedness on my part, I'm propose adding the
new command-line option as the path of least resistance.

You received this message because this project is configured to send all issue notifications to this address.
You may adjust your notification preferences at:

You received this message because you are subscribed to the Google Groups 
"reviewboard-issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To post to this group, send email to
Visit this group at
For more options, visit

Reply via email to