monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Confusing terminology between usher and monotone an


From: Stephen Leake
Subject: Re: [Monotone-devel] Confusing terminology between usher and monotone and proposed change
Date: Thu, 05 May 2011 18:57:10 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (windows-nt)

Richard Levitte <address@hidden> writes:

> I've had a closer look at the terminology used in usher and in
> monotone, and there is a part that's quite confusing:
>
> In usher terminology, different databases are served by different
> monotone server, and therefore, the URI to access them through a
> server name would be expressed as mtn://HOST/SERVER?PATTERN.
>
> In monotone terminology, the same URI is expressed as
> mtn://HOST/PATH?PATTERN.
>
> Furthermore, usher is a server in its own right, so when talking about
> the usher+monotone combination, it might be confusing to talk about a
> server, as it might not always be clear if you're talking about the
> usher server itself or one of the underlying monotone servers.
>
> Also, in usherctl, the confusion is increased, since it uses PROJECT
> to designate what usher calls SERVER and monotone calls PATH.  This is
> confusing since monotone has another idea of what a project is, and
> will just increase as soon as policy branches are in place.
>
>
> To clear the confusion, I propose that we make a terminology change in
> usher, where the term SERVER (to designate a monotone server entry in
> the usher configuration) be changed to PATH (with the implicit
> understanding that a PATH is then served by the monotone server in
> said entry).  This makes it clear how it corresponds to what's in the
> monotone documentation and leaves less (if any) confusion about what
> server you're talking about in different contexts.  And frankly, I
> like the ring of it ;-)
>
> The proposed changed involves having the key 'server' be replaced by
> 'path' in usher's configuration file.  Of course, usher should still
> understand the key 'server' for a while (say, until 2.0), but will
> then tell the user that it's deprecated and should be replaced.
> usherctl will be changed in a corresponding way.
>
> This should be implemented before releasing usher 1.0.
>
>
> Thoughts?

looks good to me, but then I've never implemented an usher setup.

-- 
-- Stephe



reply via email to

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