On Mon, Apr 20, 2015 at 11:35 PM, Mads Kiilerich <m...@kiilerich.com> wrote: > On 04/20/2015 05:55 AM, Thomas De Schampheleire wrote: >> >> On Sun, Apr 19, 2015 at 6:16 PM, Mads Kiilerich <m...@kiilerich.com> >> wrote: >> > >>> I would probably take a patch that moved the hardcoded # naming to a >>> method >>> on the PullRequest db model, similar to how we have .url . It would be >>> very >>> much like the existing .pull_request_id field so perhaps name it >>> .nice_id? >> >> Shouldn't it be symmetrical: pull_request_nice_id or something like that? > > > Probably ... but that is a long name and I'm lazy ;-) > > Right ... > >> >>> It is a bit weird that Kallithea pull request numbers are global. >>> Especially >>> in a site that is hosting repos for multiple independent users, it would >>> make sense to have per repo numbering. Would that solve your case? Will >>> your >>> repos in the different instances be named differently? >> >> No, the different instances would operate on the same repositories >> with the same names (note that we're not using Kallithea for repo >> hosting, it is a mirror). > > > Using it as a mirror is fine ... but having multiple independent instances > does not seem like something I can recommend. It would make more sense to > have multiple servers on the same database in some failover loadbalancing > setup.
The reason we planned doing such a setup is that the network latency/bandwidth between sites is not always very good. If there is one single Kallithea instance in a given site, the developers from that site get a good experience, while the developers from a remote site may suffer high latencies. With a local database + instance this would be mitigated. Your suggestion of the same database and multiple Kallithea instances: how exactly does this work? Is all locking in place? And since the database is in one place: don't you suffer from the same network latency issue? > >> Also, global IDs have the benefit of being completely standalone. If >> we have per-repo IDs, I cannot tell you 'look at pull request 5', >> because I would have to tell you which repo to look in. > > > In general I think it is a good thing to have to specify which repo a PR is > for. > > Your case of multiple series for the same repo with the same numbering > scheme ... that is just ... no! Just say no! ;-) > > Anyway, I think you can do what you want with some upstreamed refactorings > and some system for monkeypatching extensions. I will try implementing this system anyway, and look forward to your suggestions on the deployment model. Thanks, Thomas _______________________________________________ kallithea-general mailing list kallithea-general@sfconservancy.org http://lists.sfconservancy.org/mailman/listinfo/kallithea-general