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). 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.
--
Best regards,
Vladimir mailto:vladi...@thecybershadow.net
