> 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 750000. 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?)