Re: [Monotone-devel] branch naming conventions

[Zbynek Winkler]

Nathaniel Smith wrote:

> On Sun, Oct 30, 2005 at 11:14:21AM +0100, Zbynek Winkler wrote:
>  
>
> > When everything has hash-based unique id why should branches be any 
> > different? Every database would maintain mapping between the unique ids 
> > and some human readable form (which could be anything - globaly unique 
> > or not). That would allow easy (local) renaming of branches while not 
> > forcing a naming convention.
> >
> > Everything could stay the same only where now the branch name is would 
> > be the guid. Should the user want to use the guid, he/she could. But a 
> > database-local mapping could be created to assign names to the branches 
> > (not versioned). The ui code would map the names to the guids and back.
> >
> > What do you think?
> >    
> This sounds like something similar to a Pet Names proposal:
>  http://www.erights.org/elib/capability/pnml.html
>  
Nice roundup :)

> The problem with pet names systems is that they work great if you have
> control of the communications media people will be using, because then
> you can seamlessly translate between different people's views of the
> data, and everything stays all nice and secure and such.  But in real
> life, we're building tools that are supposed to slot into a rich,
> pre-existing social ecology of collaboration, and there's no way we
> can do that.  So I think there's some (insufficiently recognized!)
> onus on us as designers to try and build systems that will be secure,
> _assuming_ our transport media is, well, people chatting over IRC or
> cubical walls and on the phone and pagers and leaving each other
> postits and all the crazy opportunistic stuff that real people come up
> with to talk.  People are good at talking, they're going to keep
> using certain patterns of communication whatever we do; let's leverage
> that instead of fighting it.
>
> The most obvious example of this is using hashes to identify
> revisions; they're not _much_ harder to deal with than other schemes,
> day to day, and you get this magical thing -- once you're used to
> those hashes as being the names for revisions, then casually
> mentioning revisions over email or IRC or whatever, just like you'd do
> naturally, suddenly gives you strong end-to-end security guarantees.
> (It's also, as a side-effect, guaranteed to always and simply _work_,
> which is not the case with schemes that use local revision numbers...)
> We think that's kinda neat...
>  
Me too.

> 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).

> [snip]
>
> I know of another option that seems like it would be at least stand a
> chance of working; this was proposed by Derek Scherger a while ago.
> The idea is to actually name branches (or, I suppose, keys) something
> uninformative, like 20 bytes of pure entropy (or, for keys, a hash of
> the keypair).  Then, each db keeps a mapping ID <-> READABLE NAME.
>  
Ok, then I am not the first :). But let's keep the keys aside for a while...

> 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).

> 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 :(

> Basically, the idea is that anyone can rename branches, but each
> possible naming creates a little communications ghetto, where you can
> only talk (using monotone) to other people who use the same names.
>  
I do not think this is necessary (see above).

> [snip]
>
> 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.

Zbynek

--
http://zw.matfyz.cz/     http://robotika.cz/
Faculty of Mathematics and Physics, Charles University, Prague, Czech Republic