[Monotone-devel] Re: branch naming conventions

[Bruce Stephens]

Nathaniel Smith <address@hidden> writes:

[...]

>   -- have both local names (human readable) and global names (not
>      human readable); it's the responsibility of the people talking to
>      choose which one to use in each case.  (This is what you
>      propose.)
>      -- problem: if local names are 90% consistent between users, then
>         they will just use their local names when talking, which then
>         is not reliable.

Well, using local names would be reliable 90% of the time.  Maybe
more, in particular contexts.  And mostly, people communicate in
particular contexts.  net.venge.monotone doesn't uniquely define a
branch (there's nothing stopping me (well, nothing technical) from
importing the Subversion sources onto a branch in a new repository
that I call net.venge.monotone); we all know what it means because
we've bought into the Javaish convention, we *know* that branch
net.venge.monotone comes from venge.net, and anyway we know what
branch it is.

Maybe we want a mini-selector syntax for branches, just so that we can
make definitive references for a branch, where we fear that people
from outside the expected context might be confused?  (It could
include 8 chars of the id of the branch net.venge.monotone+0d979e72 or
something.)  But 99% of the time, the group who'd want to use them
could use local names, and everything would work.

>   -- have both local names (human readable) and global names (not
>      human readable); have a software intermediary that lets us each
>      use our local names but sneakily translates our messages so what
>      we each see is consistent.  (This is a Pet Names system.)  Not
>      viable here, because we have no way to control communications.

No, not viable, I agree.

>   -- have both local names (human readable) and global names (not
>      human readable); have a quiet software mechanism in the
>      background that works in-band to make sure the everyone likely to
>      talk out-of-band already has consistent local names.  Now people
>      can use local names when talking to each other all they want.
>      (This is the possible solution I described.)

What would go wrong with just adding a level of indirection, as
suggested.  So branches have some unique, usually not very visible,
id, and we have certs binding names to these ids.  And we have the
usual kinds of lua hooks allowing individuals to determine which certs
are valid for them---maybe even have special rules saying which of
these certs go over protocol.  Almost certainly have those rules, come
to think of it: it's likely to be convenient to have short names for
local use (where "local" probably includes several of my repositories,
but nobody else's).

That should allow me to rename a non-distributed branch easily: I just
add a new naming cert, and delete a single cert, or I just add a
simple rule to a hook that ignores that cert.

So if two people get a branch, but it's changed name inbetween, well,
probably it gained a name inbetween, so after a sync both people will
see both names.

Maybe there could be default rules, so if I pull from net.venge, then
by default, it'll only get branch-naming certs which give names
beginning "net.venge".

And for the ugly collisions and things, well, maybe we have some
things to fix up by email/irc/web and deleting certs by hand, or
fixing lua hooks, but that doesn't seem impossible.  As with the
universal names, this involves some kind of agreement to work well,
but that seems OK.

[...]