View mode: basic / threaded / horizontal-split · Log in · Help
January 25, 2011
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
"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
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
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
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
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
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
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
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
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
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
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
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
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
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
"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
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
> 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
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
"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.
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home