Vladimir Panteleev wrote:
On Tue, 25 Jan 2011 23:08:13 +0200, Nick Sabalausky <a@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.
