monotone-devel
[Top][All Lists]
Advanced

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

[Monotone-devel] Confusing terminology between usher and monotone and pr


From: Richard Levitte
Subject: [Monotone-devel] Confusing terminology between usher and monotone and proposed change
Date: Thu, 05 May 2011 10:42:41 +0200 (CEST)

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?

Cheers,
Richard ( my main focus in the nearest future will be to implement
that change, as well as changing the test structure (already working
on it) )

-- 
Richard Levitte                         address@hidden
                                        http://richard.levitte.org/

"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish



reply via email to

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