Labels: Type-Defect Priority-Medium
New issue 3277 by saa-goog...@concision.com: Different URLs for same SVN
repository no longer working
What version are you running?
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
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
https://example.com/repository_name. 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:
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 postreview.py:
repository = options.repository_url or self.info.path
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
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to firstname.lastname@example.org.
Visit this group at http://groups.google.com/group/reviewboard-issues.
For more options, visit https://groups.google.com/groups/opt_out.