On Thu, 27 Jan 2011 21:48:28 +0200, Don <nos...@nospam.com> wrote:
No. Just one repository number, and one revision number. You just need
to be sensible in how the clone numbers are assigned. That's easy.
Basically every repository has a number of clone numbers it can assign.
Every clone gets a subset of that range. Dealing with the situation when
the range has run out is a bit complicated, but quite doable, and there
are steps you can take to make it a very rare occurence.
Giving this some thought, I'm now confident that this is not possible. The
assignment algorithm must take into account all variations of imaginable
cases (cloning hierarchy up to a certain depth). We're talking about an
algorithm must give a unique ID to each node in an implicit tree, not
knowing about the state of the rest of the tree except the state of each
new node's parent. The only sensible solutions will quickly generate
humongous numbers for some or other common real-life scenarios.
I believe we're not still arguing that these numbers must also be useful
beyond their terseness and uniqueness?
I think it's easier to just use the first 5 characters from Git's SHA-1
hash.
I'm not have almost zero interest in this stuff, so I won't say any
more. I'm really just commenting that it's not difficult to envisage an
algorithm which makes exposing a random hash unnecessary.
You're welcome to not reply.
--
Best regards,
Vladimir mailto:vladi...@thecybershadow.net
