monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] usher


From: hendrik
Subject: Re: [Monotone-devel] usher
Date: Thu, 15 Apr 2010 12:17:42 -0400
User-agent: Mutt/1.5.18 (2008-05-17)

On Wed, Apr 14, 2010 at 09:50:08PM -0500, Timothy Brownawell wrote:
> On 04/14/2010 02:29 AM, Thomas Keller wrote:
>>
>> Thats right - I also wondered if its worthwhile to merge-into-dir usher
>> to the main monotone tree and include it in the base distribution. Usher
>> makes only very very little sense without monotone and if its packaged
>> right with monotone, you would not need to spend time setting up a web
>> page, bug tracker, etc pp, but the development of both could be
>> synchronized.
>
> Hm. Or do we want a separate branch, with monotone and the various tools  
> (usher, viewmtn, guitone, mtn-viz) all merge-into-dir'ed into it?
>
>> Finally, what speaks against integrating usher in monotone's base completly?
>
> As in make it all a single binary? Not sure what the benefit would be,  
> and I like the more modular approach. For instance I have a half-written  
> usher library in C# somewhere, I imagine that sort of thing would be  
> more difficult if usher was baked into monotone.

Usher can permanently monitor the incoming port, and start monotones on 
specific 
databases as needed (isn't that the way it works now?)  This also means that 
some of 
those specific monotones can be started by users working on that server 
machine, and 
by users activating monotone by other protocols (such as ssh).  There will be 
occasional mutual exclusion, but all these monotone databases remain mostly 
accessible.

This would not be the case if there was just one binary, and just one permanent 
monotone process jealously owning its flock of data bases.

-- hendrik




reply via email to

[Prev in Thread] Current Thread [Next in Thread]