Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
Beanbag, Inc. - http://www.beanbaginc.com

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

> Hi Chris,
> Thanks for a detailed response.
> One question on UUID - why can't it be cached in RB's database at the time
> of repository setup, instead of being queried from Subversion servers for
> each 'rbt post' as you described?
> On .reviewboardrc, this approach would work if the checked-out module is
> known. In our case, for example, we have at least:
> /trunk/src
> /trunk/docs
> (and a few other directories)
> - If a developer works purely on updating the user documentation, for
> example, he would just check out /trunk/docs. Which means for 'rbt post' to
> work, there needs to be /trunk/docs/.reviewboardrc.
> - Similarly, if a change does not involve anything but sources, he'd only
> check out /trunk/src - ergo, there must be /trunk/src/.reviewboardrc.
> - If a change involves both the source code modifications and user doc
> changes, he'd check out /trunk - so, adding /trunk/.reviewboardrc as well...
> I think you see where this is getting :) Putting a separate .reviewboardrc
> into each subdirectory is hardly maintainable, especially if we need to
> change it at some point. Now, imagine if we migrate the RB to a different
> server - in addition to updating multiple .reviewboardrc's for /trunk, we'd
> also need to update the .reviewboardrc in each branch - since many branches
> are still actively maintained.
> This is why we're using a property set at the top of the repository. I
> implore to add a repository name property to avoid the above maintenance
> nightmare.

That makes sense, and is a valid use case for UUID matching.

Caching is possible. It didn't used to be when the UUID code was written,
but it's worth investigating now. I'll be honest, I don't have a lot of
time to do that right now with trying to get RB 2.0 out the door, but a
patch wouldn't be too difficult. I'd accept one for caching the UUID if
someone wanted to write it.

The problem would be if you changed the repository out from underneath
Review Board, changing UUIDs. You'd need some way to reset. Maybe not worth
optimizing for, but should be considered.

Unfortunately, I don't believe the property isn't any more a solution than
.reviewboardrc. For the current reviewboard:url property, we're just
walking up the local directory stack anyway, meaning a property on / won't
work if checking out from some subdirectory. You'd still need a property in
every one of those directories, which is only slightly different than a
.reviewboardrc in every one of those directories. (The latter at least
allows for consistency with the rest of the codebase and other revision
control systems.)

If we were to fix that to check the property from the root of the remote
server (provided / isn't checked out), then there's not much difference
between that and grabbing the .reviewboardrc from the root of the remote
server. I'll admit I may be missing something, as it's been a while since
I've dealt with Subversion or our Subversion code on any real level.


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