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." _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
