Re: [Monotone-devel] branch naming conventions

[Nathaniel Smith]

On Sun, Oct 30, 2005 at 03:34:00PM +0100, Zbynek Winkler wrote:
> Nathaniel Smith wrote:
>
> >Branch and key names are similar, 
> >
> I think you are unnecessarily complicating matter by putting branches 
> and keys together. They are somewhat similar but the differences IMHO 
> prevail. Branches are like tags with mapping 1:N (instead of 1:1). What 
> I am proposing is to add one more mapping to get 1:1:N 
> (name:id:revisions instead of name:revisions), where the first 1:1 
> mapping is local only (just "UI" thing).

Branches and keys are pretty different beasts, sure, but I'm not sure
what makes you say they're different _with regard to the problems they
cause for naming_.

It doesn't much matter, though, we can certainly talk about just one
at a time if we'd rather.

> >The tricky bit is that at netsync time, we check to make sure that our
> >mapping is consistent with our peers mapping; 
> >
> I do not think we need to do this with branches. When a user initiates 
> netsync we get a pattern describing the branches to sync. We can expand 
> the pattern locally and use the mapping to convert it to list of IDs. 
> The netsync would sync the list of IDs --> no need to have the same 
> mapping on each side (this is what the PetNames you mentioned above do). 
> However we would need to add a special command to pull a new branch from 
> a remote computer where would either use the remote symbolic name or the 
> global branch ID (this would be the time to add this ID to the local 
> mappings).

Okay.  I think you missed the main point I was talking about.

We certainly _could_ do what you describe.  That part's no problem.

However, there is a problem: You and I might decide to use different
names for the same branch.  Or we might do so accidentally, like maybe
I pulled, then it got renamed on the server, then you pulled.

Okay, so this isn't actually a problem either, if you just look at it
alone. Here's what the actual problem is: names are used by people,
and people don't just sit at their computer and use their VCS and
that's all they do.  Actually, people spend a lot of time talking to
each other, in lots of different ways; a VCS tool needs to be useful
in that _ecology_ of collaboration, not just for the imaginary User
who sits alone in a room and just uses your program.

So, if we're talking, and I want to refer to a branch, how do I do
that so you understand?  There's a lot of possible solutions:
  -- use universal names, like now
  -- 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.
  -- 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.
  -- 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.)

Am I being any more convincing?  Do you see why I think consistency of
names is important?  What do you imagine happening, where today I
would tell someone on IRC "if you want to try it, check out the latest
head of net.venge.monotone.cvssync and build that"?  Should I be
saying "check out the latest head of
   73070030f7b0d0f3d4ee02545d45ca4bbe5e189f
and build that"?  Or if not, how do I know the person I'm talking to
understands?

> >consistent means, we
> >take all their (ID, NAME) pairs and all our (ID, NAME) pairs, union
> >them, and check to see if the resulting set has any duplicate IDs with
> >different NAMEs, or duplicate NAMEs with different IDs.  If so, it
> >aborts the netsync and tells you to fix up one side or the other
> >manually.  (This is very similar to the current 'epoch' support, in
> >implementation.  It could also, incidentally, replace epochs, by
> >re-implementing what we currently call "one branch with two different
> >epochs" as "two different branches with the same human-readable
> >name".)
> > 
> >
> I am afraid I do not know what 'epoch' is :(

Not that big a deal, but:
  http://www.venge.net/monotone/docs/Rebuilding-ancestry.html

> >Sorry, that was, err, probably more than you were expecting to have to
> >wade through in response to your idea :-).  Does this stuff make
> >sense?  What do you think?
> > 
> >
> It does, I just think we do not need the mapping (for branches) to be 
> globally consistent which makes it IMHO much easier.

Right, but that's where we disagree :-).

-- Nathaniel

-- 
"Lull'd in the countless chambers of the brain,
Our thoughts are link'd by many a hidden chain:
Awake but one, and lo! what myriads rise!
Each stamps its image as the other flies"
  -- Ann Ward Radcliffe, The Mysteries of Udolpho