We're using the SVN property set at the root of the repository for the same
reasons as Alexey.
I can also confirm that this approach works perfectly fine even when I have
only a subdirectory checked out.
On Wednesday, January 15, 2014 12:38:21 AM UTC-5, Christian Hammond wrote:
> Review Board - http://www.reviewboard.org
> Beanbag, Inc. - http://www.beanbaginc.com
> On Tue, Jan 14, 2014 at 7:47 PM, Alexey Neyman
> > 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:
>> (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
> 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
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/groups/opt_out.