[PATCH] pullrequests: add support for custom pull request id prefix

[Thomas De Schampheleire]

On Tue, Apr 21, 2015 at 3:21 PM, Mads Kiilerich <mads at kiilerich.com> wrote:
> On 04/21/2015 06:20 AM, Thomas De Schampheleire wrote:
>>
>> On Mon, Apr 20, 2015 at 11:35 PM, Mads Kiilerich <mads at kiilerich.com>
>> wrote:
>>>
>>>
>>>>> 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.
>
>
> We have local mirrors for the actual cloning - using
> https://bitbucket.org/Unity-Technologies/hgwebcachingproxy/commits/all and
> https://bitbucket.org/Unity-Technologies/dynapath/commits/branch/default .
>
> Are you sure you need locally hosted Kallithea instances for the web UI?
> Depending on the size of your changes and your workflow, the requirements
> for bandwidth and latency might not be that high. Especially not to justify
> the added complexity for users and admins for managing multiple instances.
>
>> 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?
>
>
> The database could perhaps be distributed, with one master for writing and
> local mirrors for reading. The database access pattern might however not be
> good for that; read only operations have too many writes.
>

What you mean here is that Kallithea is not yet fit for this model?