Hi Antony, Sorry for the delay. Your e-mail got buried in my inbox a bit. Let me see if I can help answer your questions.
1) The documentation for this is indeed light. I'm working on a whole new set of detailed guides for configuring repositories. 1a) It's generally not the preferred way, if there are alternatives, but I think for Gitolite currently, it's maybe required. Basically, we prefer to talk to the repository through some API, but Gitolite, last I checked, didn't have one we could use that met our needs. Looking at the docs now, I think that's perhaps the case. The downside to the pull method is that you run the risk of someone pushing and then immediately basing a review request off the pushed change, and hitting "File not found" errors. If Gitolite allows you to view the raw contents of a file, given a path and blob SHA, either without requiring authentication or working with Basic HTTP Auth, then you can configure the repository to use the Raw File URL mask field, as per the docs, to point to a version of that path. That would contain some markers ("<filename>" and "<revision>") that would get filled in when Review Board wants to access a given file. This is the preferred way, for Git hosting solutions that we don't or can't have direct support for. 1b) If you can use the raw file mask method, you don't need a local clone at all. 1c) You'd need an SSH key if working with a remote Git repository, in order to verify repository information and such. If it's a local clone, it's not needed. Primarily, SSH keys are used for other services, like Subversion, where you can have more detailed communication with the service over SSH. Git's remote access protocol, unfortunately, is pretty limited, and we can't do the kinds of things we need with it, hence the local clone or raw file URL methods. I'm not sure what would make it slow.. Fetching should be fast enough, and shouldn't impact Review Board that much. Assuming you have a working memcached server, Review Board will only need to fetch files once, and then they're cached for a good long while. 2) The key is indeed generated by rb-site. You definitely should keep it. We use Chef for our deployments, and do not run rb-site to create a site on deployment. Instead, we took the settings_local.py on our server and turned it into a template that Chef installed (storing some data like the database info and secret key as variables in encrypted data bags), which then are used with the template to create the final settings_local.py file). There's a fair amount of state dependent on that secret key, so keep it secret and safe, but don't replace it unless absolutely necessary. Hope that helps! Happy to clarify any of this further. And thanks about the mobile CSS :) We have a ways to go, but I hope it's been useful so far! Christian -- Christian Hammond - christ...@beanbaginc.com Review Board - https://www.reviewboard.org Beanbag, Inc. - https://www.beanbaginc.com On Thu, Feb 11, 2016 at 1:50 PM, Antony Gelberg <antony.gelb...@gmail.com> wrote: > Hi all, > > So I'm upgrading our ancient, unmaintained "who knows how this even > worked" 1.7.20 to 2.5.2. It's going well, but I have a couple of questions. > > 1) We have our own git server, running gitolite. I have read the docs but > I found them a bit lightweight on the subject: > a) There's a crontab running every minute, doing a git fetch -q. Is this > considered "normal" for a RB / git install? > b) In the repository settings, the Path is set to the local clone path, > and the Mirror Path is set to gitoli...@git.server.name:reponame. Do we > have to have a local clone? (I think the answer here is yes, from the docs, > but just want to check...) > c) We have an SSH key configured in the RB settings. I don't see the > point of the SSH key, if a crontab is already updating the local git > clone... > I ask because the server is occasionally slow to respond, but top and the > logs show nothing interesting going on (that I've noticed). I'm wondering > if doing a git fetch every minute is somehow making it hang, although I > don't see git in top at that time either, so I'm kind of clutching at > straws. I'm happy for any advice on how things *should* be configured, this > is a good time to change the config. > > 2) I see that the config file contains a random secret that I assume was > generated by rb-site install. I'd like to know if changing that will break > anything. The reason behind it is that I want to Puppetize the server > install, and I'd rather generate the config file with rb-site install, than > store it in S3 and copy it into place. Any tips on this would be really > welcome. > > The mobile CSS looks just great, by the way. :) > > Please let me know if I haven't been clear above, happy to provide more > information as necessary. > > -- > Supercharge your Review Board with Power Pack: > https://www.reviewboard.org/powerpack/ > Want us to host Review Board for you? Check out RBCommons: > https://rbcommons.com/ > Happy user? Let us know! https://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/d/optout. > -- Supercharge your Review Board with Power Pack: https://www.reviewboard.org/powerpack/ Want us to host Review Board for you? Check out RBCommons: https://rbcommons.com/ Happy user? Let us know! https://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/d/optout.