[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Confusing terminology between usher and monotone an
From: |
Hendrik Boom |
Subject: |
Re: [Monotone-devel] Confusing terminology between usher and monotone and proposed change |
Date: |
Thu, 5 May 2011 22:00:43 -0400 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
On Thu, May 05, 2011 at 06:57:10PM -0400, Stephen Leake wrote:
> 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.
Well, even though I thought I got it to work last month, I'm still
trying to figure out my usher setup (I probably forgot soemthing about
how I used it) and I've found everything confusing again. I'll retry
understanding it with Richard's not in hand, and I'll tell you if it's
become clear not in a few days.
Maybe this letter came just in time for me!
-- hendrik