D Programming Language source (dmd, phobos,etc.) has moved to github

[Don]

Vladimir Panteleev wrote:
> On Wed, 26 Jan 2011 23:22:34 +0200, Don <nospam at nospam.com> wrote:
> 
>> Vladimir Panteleev wrote:
>>> On Wed, 26 Jan 2011 06:33:35 +0200, Don <nospam at 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.