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:
> -- 
> Christian Hammond - chi...@chipx86.com <javascript:>
> Review Board - http://www.reviewboard.org
> Beanbag, Inc. - http://www.beanbaginc.com
> On Tue, Jan 14, 2014 at 7:47 PM, Alexey Neyman 
> <alexey...@gmail.com<javascript:>
> > 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.
> Christian

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