That's the same exact concept, isn't it? My understanding is that a clone of
a DVCS repository *is* a distinct DVCS repository. So, yea, like I said, you
have to specify which repository. The common dev repository. The main
stable repository. The only shared repository this small project actually
has. Or Bob's repository for what little that would be worth.
Mostly a side-note, but in many DVCS:es (git in particular, but both
bzr and hg has it too), history rewriting is allowed, even encouraged
under some particular circumstances. In that case, the SHA-1 revision
will CERTAINLY change, while even repo+number is not very reliable.
Some kernel-branches are maintained like that, for example.
Furthermore, a related hg-anecdote; Personally, for my work-flow I
often use history-rewriting to jump around, amending patches, rebasing
them before pushing, etc. I've become very accustomed to it, and find
it extremely useful. When trying out hg a while back (to make patches
for LDC IIRC), the attempted linear-history was actually one of my
biggest disappointments. I quickly ended up in a situation where all
my patches looked like a zig-zag-stacked hodgepodge of stuff, many of
them not intended to even keep in the repo. When reading the docs
about it, the only useful suggestion I found was to create a new repo,
and cherry-pick what I wanted from the old. It's possible this were
mostly due to my inexperience with Hg, but it strengthened my
conviction that the unrealistic linear-numbers of a non-linear history
are really just shoe-horning in something for newbie-comfort, but
quite off as a model. For me, It is the deal-breaker for hg.
I don't understand why you think I'm claiming anything of the sort. I never
said anything like that. I keep saying over and over and over and over and
over and over and over.changeset number **PLUS WHICH REPOSITORY (and
maybe branch, depending how the given system chooses to work)**
How should you linearly number the two chains A B C and A D C
? Is it A, B, D, C or A, D, B, C? Should they be inter-vowen by
commit-time, or what?
Additionally, Hg's approach provides a trivial way to disambiguate hash
collisions. I know that Git book brushes it off as very rare, but it's
not
as if nobody's ever going to run into it.
Um, what method is that?
Version number together with being specific about which repository.
Again, version-number + repo is not 100% when history-rewrite is possible.
Also, saying that SHA-1 hash collisions are very rare is a bit of an
understatement.
Point is, it's possible and it's going to happen at least to someone, and
frankly, such things *have* happened. Winning the lottery and getting hit by
lighting are *extremely* rare, and yet there are a *lot* of people who have
had it happen. The problem is they're taking rare (doesn't matter what
superlative is used) and pretending it's the same as impossible. Airplane
crashes and major earthquakes are extremely rare, but they sure as hell plan
for what happens should such an event occur.
Getting hit by lightning isn't really on the same scale as SHA-1 collisions.
According to Wolfram Alpha, the odds of being struck by lightning in a
given year is one in 75. If I've understood things roughly right,
(probabilities aren't my strong side) the best possible attack for
SHA-1 requires 2^52 attempts (Note: intentional attack, pure random
chance is likely MUCH higher). That means that, given a very big
project of 1 million commits (2^20, by comparison Linux is at 232k
atm), the chance of intentionally hitting a collision is 1 in 2^32 =
4billion.
Suffice to say, comparatively there might be a prospering market for
current-insulating clothing.
I guess, when every household on earth are running it's own
kernel-project, git might have to upgrade to SHA-512. (Hg too, btw. I
think the REAL, internal revision-id:s for HG is sha-1 too, aren't
they?)
