Vladimir Panteleev wrote:
On Wed, 26 Jan 2011 23:22:34 +0200, Don <nos...@nospam.com> wrote:
Vladimir Panteleev wrote:
On Wed, 26 Jan 2011 06:33:35 +0200, Don <nos...@nospam.com> wrote:
I think this is a fallacy. It only applies if you
(1) *completely disallow* any centralisation -- which I don't think
ever happens in practice!
What about the Linux kernel? There's Linus's git repo, and lots of
repos maintained by others (e.g. Linux distros). The other distros
are not a superset of Linus's repo, they have their own branches with
various project-specific patches and backports. Git was written for
this specifically.
Yes, but each distro has a trunk, in which all commits are ordered by
time. There's always an official version of every branch.
Ordered by time of what? Time of merging into the branch? That's not
very useful, is it? They can't be ordered by time of authorship, for
certain.
"Official" is technically meaningless in a DVCS, because no repository
is holy by design (otherwise it wouldn't be really distributed).
Yes, in theory that's true. In practice, I don't believe it.
Just because you're using a DVCS doesn't mean you have no project
organisation whatsoever. There's always going to be a repository that
the release is made from.
If the
maintainer of a repository becomes MIA, anyone can take over without any
problems.
and (2) demand that cloning a repository be an entirely read-only
operation (so that the repository doesn't know how many times it has
been cloned)
and (3) demand that the revision numbers behave exactly as they do
in svn.
Then you're suggesting that the commit identifiers basically contain
the clone history?
Yes, I think it could be done that way. Identifier would be composed
of clonenumber+commitnumber. Where it is the location of the original
change. Yes, there are difficulties with this scheme, but I think they
are the same challenges as for implementing merges on a centralised
VCS such as Subversion. I don't think there's anything insurmountable.
Then a clone of a clone of a clone of a clone needs four clone numbers,
plus a revision number. It'd look something like 5:1:2:1:1056.
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.
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.
