Re: [Monotone-devel] branch naming conventions

2005-10-30 Thread Zbynek Winkler
Nathaniel Smith wrote: 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

Re: [Monotone-devel] branch naming conventions

2005-10-30 Thread Daniel Carosone
Naming is always interesting, and the source of many arguments :) With respect to key naming, I agree entirely that the internal representation of a key id should be based on a hash of the key material. Ascribing a name to a key should be done with certificates - signed attestations by other trus

Re: [Monotone-devel] branch naming conventions

2005-10-30 Thread 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

Re: [Monotone-devel] branch naming conventions

2005-10-30 Thread Nathaniel Smith
On Sun, Oct 30, 2005 at 11:57:16AM -0500, Ethan Blanton wrote: > Nathaniel Smith spake unto us the following wisdom: > > This is also somewhat problematic (though this hasn't come up as > > much yet, though it probably will as monotone usage grows), > > because it means that if the,

Re: [Monotone-devel] branch naming conventions

2005-10-30 Thread Ethan Blanton
Nathaniel Smith spake unto us the following wisdom: > This is also somewhat problematic (though this hasn't come up as > much yet, though it probably will as monotone usage grows), > because it means that if the, say, "[EMAIL PROTECTED]" key goes bad, > like it gets compromised

Re: [Monotone-devel] branch naming conventions

2005-10-30 Thread 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

Re: [Monotone-devel] branch naming conventions

2005-10-30 Thread Nathaniel Smith
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

Re: [Monotone-devel] branch naming conventions

2005-10-30 Thread Zbynek Winkler
Richard Levitte - VMS Whacker wrote: In message <[EMAIL PROTECTED]> on Sun, 30 Oct 2005 11:14:21 +0100, Zbynek Winkler <[EMAIL PROTECTED]> said: zwin> When everything has hash-based unique id why should branches be any zwin> different? Every database would maintain mapping between the unique

Re: [Monotone-devel] branch naming conventions

2005-10-30 Thread Richard Levitte - VMS Whacker
In message <[EMAIL PROTECTED]> on Sun, 30 Oct 2005 11:14:21 +0100, Zbynek Winkler <[EMAIL PROTECTED]> said: zwin> When everything has hash-based unique id why should branches be any zwin> different? Every database would maintain mapping between the unique ids zwin> and some human readable form

Re: [Monotone-devel] branch naming conventions

2005-10-30 Thread Zbynek Winkler
Nathaniel Smith wrote: The branch naming conventions debate came up on IRC again today: http://colabti.de/irclogger/irclogger_log/monotone?date=2005-10-29,Sat&sel=19#l140 So I made up a page for people to look at some options and gather some opinions...: http://venge.net/monotone/wiki/Branch

[Monotone-devel] branch naming conventions

2005-10-30 Thread Nathaniel Smith
The branch naming conventions debate came up on IRC again today: http://colabti.de/irclogger/irclogger_log/monotone?date=2005-10-29,Sat&sel=19#l140 So I made up a page for people to look at some options and gather some opinions...: http://venge.net/monotone/wiki/BranchNamingConventions -- Na