Hi Alexey,

On Tue, Jan 14, 2014 at 7:00 PM, Alexey Neyman <alexey.ney...@gmail.com>wrote:

> Hi David,
> On Tuesday, January 14, 2014 6:27:32 PM UTC-8, David Trowbridge wrote:
>> Alexey,
>> Responses inline
>> On Tue, Jan 14, 2014 at 6:14 PM, Alexey Neyman <alexey...@gmail.com>wrote:
>>> 1. When I tried to invoke post-review (yes, I still have to use that -
>>> see the second question as to "why") on a working copy which had some files
>>> renamed, it printed the following message:
>>> One or more files in your changeset has history scheduled with commit.
>>> Please try again with '--svn-show-copies-as-adds=y/n'
>>> However, post-review does not support this option:
>>> $ post-review --svn-show-copies-as-adds=n
>>> The "post-review" tool is deprecated in favor of the"rbt" suite of
>>> commands. post-review will go away in RBTools 0.6.x.
>>> Usage: post-review [-pond] [-r review_id] [changenum]
>>> post-review: error: no such option: --svn-show-copies-as-adds
>> This is an oversight. A third-party patch introduced the
>> --svn-show-copies-as-adds in the backend, but didn't include the option in
>> post-review. We'll get a patch in to fix it for 0.5.5, and I've attached
>> that patch here if you'd like to try it out.
> Thanks, it works.

We just rolled out 0.5.5, which should have this plus a Subversion
repository fix.

>  2. As to using post-review instead of 'rbt post': in our set up,
>>> post-review works but 'rbt post' doesn't. The reason is that our SVN
>>> repository is configured in RB with file:// protocol, while developers
>>> access it using svn:// protocol. The reasons for this configuration is to
>>> reduce the load on the server (since RB is running on the same machine, why
>>> should it go over the network when it can access repository directly). This
>>> also allows RB to see the repository without a dedicated RB user.
>> We're going to be improving the way that rbt post (and post-review) match
>> SVN repositories on the server. 0.5.5 will include this change:
>> https://reviews.reviewboard.org/r/5248/ , which will let you pass in the
>> repository name through the --repository-url flag (or associated REPOSITORY
>> config key). For the 0.6 release, we'll be separating this out into a
>> --repository setting.
> Does this mean that every post-review invocation would have to be
> performed with this --repository-url option? Not very convenient, IMO.
> I think it would be much easier if RB
> - compared SVN repository UUIDs - these are guaranteed to be the same,
> regardless of how the repository is accessed
> OR
> - allowed to store this "repository URL" in the repository itself, same as
> it does with the URL to the ReviewBoard (this way, rbt can obtain the
> property from by running 'svn propget')
> OR
> - allowed to configure repositories with "also-can-be-accessed-as" list of
> URLs

We're trying to get people to standardize on a .reviewboardrc file in the
repository containing the configuration. That's been the recommended setup
for years. It's easier to support and is guaranteed to work better and

The support for storing in properties is, frankly, something I wish I
didn't add back in the day. Maybe I could be convinced to add an equivalent
property for the repository name, but I'm on the fence about that.

Most of the code for UUIDs is still there, but it looks like it just didn't
get ported to rbt post. We can probably add that, but I have to warn you
that UUIDs are always going to be significantly slower than having a
.reviewboardrc file with a repository name. Review Board has to, with every
post, scan the UUIDs of all the repositories it knows about until it finds,
and this doesn't scale well. For large installs, this can even timeout the
request, particularly when Subversion servers are being slow to respond.

An "Also-can-be-accesed-list" was considered at one point, but honestly,
we're unlikely to ever do it. It goes down a path that's detrimental. A
list isn't enough for these sort of matches. Some repositories require a
username in the URL, so we'd have to support pattern matching. That means
we'd then have to fetch all repositories in the database and pattern match
across them all, which won't be efficient enough for large installs that
have hundreds of repos.

By including a .reviewboardrc and setting REPOSITORY = "<name>" (which
should now work as of RBTools 0.5.5), you'll get the fastest post speed and
better future compatibility.


Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/
Sign up for Review Board hosting at RBCommons: https://rbcommons.com/
Happy user? Let us know at http://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/groups/opt_out.

Reply via email to