Nick Sabalausky Wrote:
Robert Clipsham rob...@octarineparrot.com wrote in message
news:ihnk80$fsf$1...@digitalmars.com...
On 25/01/11 22:28, Nick Sabalausky wrote:
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)**
Person A has a repository with one branch, 'default' and has made two
commits. The current revision number is 1.
Person B clones the repository and creates a branch, 'ver2', and makes two
commits. The revision number in his repository is now 3, it is still 1 in
person A's.
Person A makes a commit, his revision 2. B switches back to the 'default'
branch, and makes another commit. His revision 4. A pulls from the
default branch, now B's revision 4 == A's revision 3.
It's very easy for the revision numbers to get out of sync like this.
Right, I already understood all of that. But consider the following scenario
(And I realize that neither Hg nor Git work exactly like this, but until
Lutger mentioned the extra details in git describe --tags it sounded like
Git was much further away from this than Hg is):
Adam starts a repository:
dvcs://joes-fancy-dvcs-hosting.org/users/Adam/SuperApp
It's Adam's project, so that could be considered the main official repo.
Adam makes five commits in the default default branch. His current
revision is:
dvcs://joes-fancy-dvcs-hosting.org/users/Adam/SuperApp/default/4
Behind the scenes, that revision is associated with an SHA-1 hash of
df3a9 This same revision, thus, could also be referred to as:
dvcs://joes-fancy-dvcs-hosting.org/users/Adam/SuperApp/hashes/df3a9...
But usually that's only used behind-the-scenes. Adam never cares about it
and neither do any of the other SuperApp contributors. But the DVCS often
uses it internally. (Are the hashes normally assiciated with a specific
branch? If so, then just consider it SuperApp/default/hashes/df3a9...
instead of SuperApp/hashes/df3a9...).
Now, along comes Bob who clones Adam's SuperApp repo. Bob's copy of the same
revision is:
dvcs://joes-fancy-dvcs-hosting.org/users/Bob/SuperApp/default/4
Naturally, he also has the same hash as Adam:
dvcs://joes-fancy-dvcs-hosting.org/users/Bob/SuperApp/hashes/df3a9...
Then Adam and Bob start making commits, updates, pushes, pulls, etc, and
their revision numbers get out-of-sync. Adam and Bob are talking on a
newsgroup, and Adam mentions a super-cool improvement he just committed:
dvcs://joes-fancy-dvcs-hosting.org/users/Adam/SuperApp/default/81
Adam doesn't know this, but that just happens to have the hash 78ac1...
and thus be AKA:
dvcs://joes-fancy-dvcs-hosting.org/users/Adam/SuperApp/hashes/78ac1...
Bob wants Adam's new change, so he tells his DVCS to merge in:
dvcs://joes-fancy-dvcs-hosting.org/users/Adam/SuperApp/default/81
No problem. Bob didn't ask his DVCS for r81, he asked it for Adam's r81.
This revision now becomes Bob's:
dvcs://joes-fancy-dvcs-hosting.org/users/Bob/SuperApp/default/117
dvcs://joes-fancy-dvcs-hosting.org/users/Bob/SuperApp/hashes/78ac1...
Since Adam announced this on a NG, Carlos also saw it and grabbed the new
change:
dvcs://carlos-coder.co.uk/SuperApp/default/94
dvcs://carlos-coder.co.uk/SuperApp/hashes/78ac1...
They all start to use it, but Bob discovers a critical problem with it. So
Bob tells the NG to avoid:
dvcs://joes-fancy-dvcs-hosting.org/users/Adam/SuperApp/default/81
Or, Bob might have referred to it with his own revision instead (Maybe
Adam's account was temporarily down):
dvcs://joes-fancy-dvcs-hosting.org/users/Bob/SuperApp/default/117
So Carlos tells his DVCS to revert that URI. To do this, Carlos's DVCS looks
up Adam's or Bob's URI and finds the associated hash: 78ac1 Then it
looks at Carlos's own copy of the repo, sees the active branch is default,
and finds the revision in default associated with the hash 78ac1...,
which is:
dvcs://carlos-coder.co.uk/SuperApp/default/94
Which then gets reverted.
This looks to me like an awful solution in search for a problem.
The commit hash is the internal ID mainly used by git itself. If you want to
communicate commits to other developers you have better means to do so. Let's
emphasize that auto incremented numbers is NOT those means.
commit have sha1 hashes Just like people have ID numbers to identity them (or
the social security number in the US). That doesn't mean I would call you in
conversation: person#122345445 I'll call you by a HUMAN GIVEN NAME (e.g.
Nick).
If you want to refer to a git commit on the NG simply tag it with a meaningful
name such as:
