Re: Confusing terminology between usher and monotone and proposed change
Stephen Leake <[email protected]>
| Newsgroups | gmane.comp.version-control.monotone.devel |
|---|---|
| Message-ID | <[email protected]> |
Richard Levitte <[email protected]> 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