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.
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.
