Nathaniel Smith <[EMAIL PROTECTED]> 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. [...] _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
