January 25, 2011
"Lutger Blijdestijn" <lutger.blijdestijn@gmail.com> wrote in message news:ihnh65$ak4$1@digitalmars.com...
> Nick Sabalausky wrote:
>
>> "Lutger Blijdestijn" <lutger.blijdestijn@gmail.com> wrote in message news:ihn21d$2esd$1@digitalmars.com...
>>> Nick Sabalausky wrote:
>>>
>>>> "David Nadlinger" <see@klickverbot.at> wrote in message news:ihkub8$1ia4$1@digitalmars.com...
>>>>> On 1/24/11 10:20 PM, Nick Sabalausky wrote:
>>>>>>>> Does Git really not have real revision/changeset numbers?
>>>>>>>
>>>>>>>[.]
>>>>>>>
>>>>>>
>>>>>> Not that I've actually used DVCSes much yet, but my understanding is
>>>>>> that the same can be set of Hg and yet Hg handles revision/changeset
>>>>>> numbers just
>>>>>> fine. The nice things (plural) about those is that they're both
>>>>>> readable
>>>>>> and
>>>>>> comparable.
>>>>>
>>>>> Hg has no ?real revision/changeset numbers? either - there is a
>>>>> more-or-less-monotonic number assigned to the various changesets, but
>>>>> it's only valid for a single, *local* checkout, using them e.g. in a
>>>>> NG
>>>>> post would be a very wrong thing to do
>>>>> (http://mercurial.selenic.com/wiki/RevisionNumber).
>>>>>
>>>>
>>>> Even without really using DVCSes it always seemed clear to me that an
>>>> incremented number would be relative to a particular branch. So if you
>>>> specify what branch you're talking about (which could usually just be
>>>> assumed to be the main official one unless otherwise specified),
>>>> shouldn't
>>>> that be enough?
>>>>
>>>>> Git supports a relative notation as well, which is what I personally
>>>>> want
>>>>> to use most of the time anyway (e.g. HEAD^, master~4, something@{"1
>>>>> year ago"}, .).
>>>>
>>>> Ah, so it *does* then? Great! Happen to have a link that explains it?
>>>>
>>>
>>> This covers most of it to see what's possible:
>>>
>>> http://progit.org/book/ch6-1.html
>>>
>>> You can customize git log with a format string, try this for example:
>>>
>>> git log --pretty=format:"%h - %an, %ar : %s %d"
>>>
>>
>> Ahh, that's not remotely what I was hoping it was. Everything is all relative to the current version which means that *every* time you commit, *every* changeset gets completely renamed (HEAD@{5} becomes HEAD@{6}, etc), and there doesn't appear to be any syntax to refer to the next changeset (only the previous), which makes it barely useful at all. And not only that, but they *dissapear* after a certain amount of time.
>>
>> 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.
>
> I see, you want a convenient name for a particular commit, is that it? But even the hg revision number is discouraged to be used to talk with others, this is from the manual:
>
> "It is a strictly local convenience identifier (...) Revision numbers
> referring to changesets are very likely to be different in another copy of
> a
> repository. Do not use them to talk about changesets with other people"
>

This part is the whole crux of it:

"Revision numbers referring to changesets are very likely to be different in another copy of a repository."

Which is why I keep saying "plus which repository you're talking about". How is that ambinguous or problematic? People keep implying that it is ambiguous or problematic, but no one says "how" except when rehashing the strawman of pretending as if I had never said "plus which repository you're talking about".

...Plus which repository you're talking about.
...Plus which repository you're talking about.
...Plus which repository you're talking about.
.
.
.
.
...Plus which repository you're talking about.

> When there is a lot of branching going on (even in a local repository)
> these
> revisions numbers become useless and confusing. A unique identifier is
> much
> more useful.

Agreed. And something that incorporates both a sequential number and a sensible system of referring to a particular repository (some sort of URI, for instance) can be used as not only a unique identifier, but a unique identifier that's actually readable and means something.


> You can't expect other people to piece together how the revision number has come to be, that is extremely brittle.
>

They don't need to piece it together because you can just say...

...which repository you're talking about.
...which repository you're talking about.
...which repository you're talking about.
.
.
.
.
...which repository you're talking about.
.
.
.
.
.




January 25, 2011
Vladimir Panteleev wrote:
> 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.

A version number is fundamentally linear, and so will not work very well on any sort of revision graph that is not a line. As soon as you branch or fork, it breaks down.
January 25, 2011
Robert Clipsham wrote:
> As an aside, I applaud the move to git, much needed! I may be advocating hg here, but I'm no purist, I'm perfectly happy to jump camp depending on what the developers are using... And git is a huge improvement on SVN :D

The tipping point for me was noticing that while many debated Hg vs git, nobody argued for SVN!
January 25, 2011
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. Now if person B mentioned revision 2, A will not see the same commit as B when looking at it, and has no way of specifying to look in B's repository - A doesn't have access to B's 'ver2' branch until he pulls it (or B pushes it). There are any number of other cirumstances which could easily cause this in a DVCS, and this is without reordering commits etc.

This said, I still like them, and they are really useful for small projects :)

-- 
Robert
http://octarineparrot.com/
January 25, 2011
On 1/25/11 11:28 PM, Robert Clipsham wrote:
> For all the nay-sayers to numbers in revisions - unless you're working
> on huge projects with lots of developers,[…]

Erm, no offense intended, but »lots« seems to be pretty much everything above a single one for me – as soon as you'll use Mercurial like an actual DVCS, revision numbers will inevitably differ among the various repository clones.

For a small D-related example, just compare the revision numbers in the main Bitbucket repo and Alexey's personal one – and guess what you'll see. And unfortunately, LDC isn't quite »huge«.

I was skeptical about not having revision numbers available back when I started to use Git as well, but I still have to encounter a single situation in my workflow where I wouldn't have to look up the SVN rev referring to a particular commit (when I have to search through the logs anyway, I don't care about whether I have to use the hash or a SVN-style rev anyway), but still couldn't use some relative notation, possibly in combination with local branches/tags…

David
January 25, 2011
Nick Sabalausky wrote:


...
> 
>> You can't expect other people to piece together how the revision number has come to be, that is extremely brittle.
>>
> 
> They don't need to piece it together because you can just say...
> 
> ...which repository you're talking about.
> ...which repository you're talking about.
> ...which repository you're talking about.
> .
> .
> .
> .
> ...which repository you're talking about.
> .
> .
> .
> .
> .

ok ok ok ok ok I get it. I spend some quality time with google and have found this:

$ git describe --tags

phobos-2.046-664-g938e1cc


So phobos is at the 664th commit since 2.046


http://gitfu.wordpress.com/2008/05/25/git-describe-great-another-way-to- refer-to-commits/

January 25, 2011
On 25/01/11 22:48, Walter Bright wrote:
> Robert Clipsham wrote:
>> As an aside, I applaud the move to git, much needed! I may be
>> advocating hg here, but I'm no purist, I'm perfectly happy to jump
>> camp depending on what the developers are using... And git is a huge
>> improvement on SVN :D
>
> The tipping point for me was noticing that while many debated Hg vs git,
> nobody argued for SVN!

You have much to learn young Padawan! May the force be with you.

-- 
Robert
http://octarineparrot.com/
January 25, 2011
"Lutger Blijdestijn" <lutger.blijdestijn@gmail.com> wrote in message news:ihnkgk$g8d$1@digitalmars.com...
> Nick Sabalausky wrote:
>
>
> ...
>>
>>> You can't expect other people to piece together how the revision number has come to be, that is extremely brittle.
>>>
>>
>> They don't need to piece it together because you can just say...
>>
>> ...which repository you're talking about.
>> ...which repository you're talking about.
>> ...which repository you're talking about.
>> .
>> .
>> .
>> .
>> ...which repository you're talking about.
>> .
>> .
>> .
>> .
>> .
>
> ok ok ok ok ok I get it. I spend some quality time with google and have found this:
>
> $ git describe --tags
>
> phobos-2.046-664-g938e1cc
>
>
> So phobos is at the 664th commit since 2.046
>
>
> http://gitfu.wordpress.com/2008/05/25/git-describe-great-another-way-to- refer-to-commits/
>

Ahh, now *that's* nice. All it needs now (and maybe it already has it) is to allow something like "detailedtag{local:phobos-2.046-664}" in place of hashes or HEAD@{7} and have it just figure out and use the hash by itself.


January 25, 2011
> 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?)
January 26, 2011
"Robert Clipsham" <robert@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.