[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Confusing terminology between usher and monotone an
Re: [Monotone-devel] Confusing terminology between usher and monotone and proposed change
Thu, 05 May 2011 18:57:10 -0400
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
> 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.
looks good to me, but then I've never implemented an usher setup.