Re: [Monotone-devel] Re: Proposal for human readable revision IDs

[Nathaniel Smith]

On Mon, Sep 12, 2005 at 11:04:30AM -0700, Steven Grimm wrote:
> Is there any significant performance penalty to having zillions of tags 
> in the system? I think most people's objections to the hashcodes would 

Not in particular; they take up space in the repo and bandwidth in
netsync, is all.  (Certs take up a bit more space then you would
expect, because RSA signatures are a little hefty.  Squinting at 'db
info' output on the monotone repo, it looks like the average cert size
is ~350 bytes.)

> be be satisfied with a hook script that auto-tags revisions with a much 
> shorter, likely-but-not-guaranteed unique, value at commit time 
> (username + timestamp, DB name + autoincremented serial number, etc.) I 

Timestamps seem about as opaque for normal use as hashes (they're
also just a long string of numbers), and you have to type more of them
to get uniqueness.

Where do DB names come from?

> know if I had that, I'd probably never refer to a hex revision ID. What 
> happens when there's a name collision between tags during a synchronize, 
> anyway?

Both tags win -- the t: selector can be ambiguous, just like, say, the
b: selector.  If you try to refer to t:foo where there are multiple
revisions tagged "foo", monotone will list them and tell you to figure
out which one you wanted.

-- Nathaniel

-- 
"...All of this suggests that if we wished to find a modern-day model
for British and American speech of the late eighteenth century, we could
probably do no better than Yosemite Sam."