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 - [email protected] <javascript:> > Review Board - http://www.reviewboard.org > Beanbag, Inc. - http://www.beanbaginc.com > > > On Tue, Jan 14, 2014 at 7:47 PM, Alexey Neyman > <[email protected]<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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
