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

[Jonathan M Davis]

On Tuesday 25 January 2011 20:33:35 Don wrote:
> Vladimir Panteleev wrote:
> > On Tue, 25 Jan 2011 23:08:13 +0200, Nick Sabalausky <a at a.a> wrote:
> >> Browsing through http://hginit.com/index.html, it looks like with Hg,
> >> everything works just as well as with SVN, the only difference being
> >> that you need to remember to specify which repository you're talking
> >> about whenever you give a number.
> > 
> > Not just what repository, but what clone of the repository! It's
> > explained in http://hginit.com/05.html. The number only makes sense for
> > the clone of the repository you're working on right now - basically you
> > can't tell that number to anyone, because it might mean something
> > entirely different for them.
> > 
> >> Obviously I'm not saying "DMD should have gone Hg", I'm just kinda
> >> shocked
> >> by how horrid Git's approach is for referring to changesets.
> >> (Personally, that alone would be enough to get me to use Hg instead of
> >> Git for my own projects. Heck, I've become pretty much sold on the idea
> >> of DVCS, but because of this I think I'd actually sooner use SVN for a
> >> new project than
> >> Git.)
> > 
> > I think you need to take some time and think about it. It's impossible
> > to use a global incrementing revision number with any DVCS!
> 
> 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!
> 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.
> 
> The SHA1 hashes are how many bits??? Enough for one commit from every
> person on earth, every few minutes, for hundreds of years!!!! That's a
> ridiculously inefficient method of identifying changesets.
> Looks like a strawman argument to me. "It can't be done", but only
> because unnecessary requirements have been added.

The main reason for the SHA1 is to verify that the repository hasn't been 
tampered with or corrupted. I suspect that Linus decided to just use it as the 
identifier for the changeset, because then you only have one number to worry 
about, not two (the hash and the changeset number). And given the difficulties 
with regards to incremental revision numbers in a distributed VCS (particularly 
one which allows for changes to the revision history), I can understand deciding 
to just not bother with them. Whether that was the best decision or not is 
another matter. Regardless, I don't think that SHA1 was picked as a changeset ID 
because of how many revision numbers it can hold.

- Jonathan M Davis