Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Russel Winder wrote: On Fri, 2011-01-28 at 12:43 -0300, Leandro Lucarella wrote: Russel Winder, el 28 de enero a las 11:30 me escribiste: [ . . . ] Bazaar does indeed have revision numbers per branch. Note that branch and repository is a different concept in Bazaar, unlike Git and Mercurial where they are fundamentally the same. WRONG about Git. Depends what you thought I was saying . . . AFAIK only in Darcs branch and repository is the same. . . . I think you misunderstood what I meant by my statement. What I was trying to say was that Git and Mercurial have effectively the same ideas of repository and branch (at least from a surface usage perspective -- there are significant differences if you delve deeply). Bazaar has a very different idea of what branch and repository are. So in this respect Git and Mercurial are in the same equivalence class and Bazaar is in a different one. I have no idea where Darcs would sit, I have never used it beyond trying to compile Haskell this time last year. In Mercurial (and AFAIK Git), branches and repositories are completely different concepts. A repository is a folder on your hard drive. A branch is a history line inside a repository so it's not that different from Bazaar. The only difference I see is that Bazaar allows you to clone a single branch (i.e to create a repository that will only contain that single branch) whereas a clone of a Mercurial repository will always contain all the branches that the parent had (don't know about Git). Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
On Sat, 2011-01-29 at 11:18 +0100, Jérôme M. Berger wrote: [ . . . ] In Mercurial (and AFAIK Git), branches and repositories are completely different concepts. A repository is a folder on your hard drive. A branch is a history line inside a repository so it's not Definitely, this is not at issue. The way Git and Mercurial store information about branches and tags within a repository is very different. This leads to a few observable differences in the way branches and commits behave, but in the main there is similarity not difference. Caveat Git's index of course. that different from Bazaar. The only difference I see is that Bazaar allows you to clone a single branch (i.e to create a repository that will only contain that single branch) whereas a clone of a Mercurial repository will always contain all the branches that the parent had (don't know about Git). This is not quite the right view of Bazaar. In Bazaar, the branch is the only thing that exists: each branch is a standalone entity that may or may not have a working tree. Bazaar also has shared repositories which can act as containers of branches, allowing related branches to share common information thereby saving resources. This is a very, very different concept of repository compared to Mercurial or Git. In Bazaar you do not branch repositories, you branch branches -- which may (or may not) be stored in repositories. As you say with Git and Mercurial you clone repositories. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
On Thu, 2011-01-27 at 13:33 -0800, Bill Baxter wrote: On Thu, Jan 27, 2011 at 1:13 PM, Nick Sabalausky a@a.a wrote: [ . . . ] Yea, and that's pretty much the original thing I was saying: It's nice that Hg seems to have it, but Git doesn't appear to be particularly interested in it. I think it's very handy for all the reasons you said. I don't think I've every had to use a big hex string when dealing with mercurial. Maybe once or twice max. Most of the stuff you do with repo history as an individual developer is all about the local copy of the tree on your system. Globally unique identifiers aren't needed for that. It looks like Bzr does something similar. Not sure why Git hasn't gotten this particular nicety. Bazaar does indeed have revision numbers per branch. Note that branch and repository is a different concept in Bazaar, unlike Git and Mercurial where they are fundamentally the same. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Am 28.01.2011 12:30, schrieb Russel Winder:
On Thu, 2011-01-27 at 13:33 -0800, Bill Baxter wrote:
On Thu, Jan 27, 2011 at 1:13 PM, Nick Sabalauskya@a.a wrote:
[ . . . ]
Yea, and that's pretty much the original thing I was saying: It's nice that
Hg seems to have it, but Git doesn't appear to be particularly interested in
it.
I think it's very handy for all the reasons you said. I don't think
I've every had to use a big hex string when dealing with mercurial.
Maybe once or twice max. Most of the stuff you do with repo history
as an individual developer is all about the local copy of the tree on
your system. Globally unique identifiers aren't needed for that. It
looks like Bzr does something similar. Not sure why Git hasn't gotten
this particular nicety.
Bazaar does indeed have revision numbers per branch. Note that branch
and repository is a different concept in Bazaar, unlike Git and
Mercurial where they are fundamentally the same.
I don't know Git but in Mercurial speech a branch is what you get when
using the 'hg branch' command. It's like a tag but a commit can only
belongs to exactly one branch ('default' is the default branch). All
commits to all branches are put together in one repository.
Mafi
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
On Thu, 27 Jan 2011 21:48:28 +0200, Don nos...@nospam.com wrote: No. Just one repository number, and one revision number. You just need to be sensible in how the clone numbers are assigned. That's easy. Basically every repository has a number of clone numbers it can assign. Every clone gets a subset of that range. Dealing with the situation when the range has run out is a bit complicated, but quite doable, and there are steps you can take to make it a very rare occurence. Giving this some thought, I'm now confident that this is not possible. The assignment algorithm must take into account all variations of imaginable cases (cloning hierarchy up to a certain depth). We're talking about an algorithm must give a unique ID to each node in an implicit tree, not knowing about the state of the rest of the tree except the state of each new node's parent. The only sensible solutions will quickly generate humongous numbers for some or other common real-life scenarios. I believe we're not still arguing that these numbers must also be useful beyond their terseness and uniqueness? I think it's easier to just use the first 5 characters from Git's SHA-1 hash. I'm not have almost zero interest in this stuff, so I won't say any more. I'm really just commenting that it's not difficult to envisage an algorithm which makes exposing a random hash unnecessary. You're welcome to not reply. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
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:
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Russel Winder, el 28 de enero a las 11:30 me escribiste: On Thu, 2011-01-27 at 13:33 -0800, Bill Baxter wrote: On Thu, Jan 27, 2011 at 1:13 PM, Nick Sabalausky a@a.a wrote: [ . . . ] Yea, and that's pretty much the original thing I was saying: It's nice that Hg seems to have it, but Git doesn't appear to be particularly interested in it. I think it's very handy for all the reasons you said. I don't think I've every had to use a big hex string when dealing with mercurial. Maybe once or twice max. Most of the stuff you do with repo history as an individual developer is all about the local copy of the tree on your system. Globally unique identifiers aren't needed for that. It looks like Bzr does something similar. Not sure why Git hasn't gotten this particular nicety. Bazaar does indeed have revision numbers per branch. Note that branch and repository is a different concept in Bazaar, unlike Git and Mercurial where they are fundamentally the same. WRONG about Git. AFAIK only in Darcs branch and repository is the same. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- You can try the best you can If you try the best you can The best you can is good enough
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
Vladimir Panteleev wrote: On Wed, 26 Jan 2011 23:22:34 +0200, Don nos...@nospam.com wrote: Vladimir Panteleev wrote: On Wed, 26 Jan 2011 06:33:35 +0200, Don nos...@nospam.com wrote: I think this is a fallacy. It only applies if you (1) *completely disallow* any centralisation -- which I don't think ever happens in practice! What about the Linux kernel? There's Linus's git repo, and lots of repos maintained by others (e.g. Linux distros). The other distros are not a superset of Linus's repo, they have their own branches with various project-specific patches and backports. Git was written for this specifically. Yes, but each distro has a trunk, in which all commits are ordered by time. There's always an official version of every branch. Ordered by time of what? Time of merging into the branch? That's not very useful, is it? They can't be ordered by time of authorship, for certain. Official is technically meaningless in a DVCS, because no repository is holy by design (otherwise it wouldn't be really distributed). Yes, in theory that's true. In practice, I don't believe it. Just because you're using a DVCS doesn't mean you have no project organisation whatsoever. There's always going to be a repository that the release is made from. If the maintainer of a repository becomes MIA, anyone can take over without any problems. and (2) demand that cloning a repository be an entirely read-only operation (so that the repository doesn't know how many times it has been cloned) and (3) demand that the revision numbers behave exactly as they do in svn. Then you're suggesting that the commit identifiers basically contain the clone history? Yes, I think it could be done that way. Identifier would be composed of clonenumber+commitnumber. Where it is the location of the original change. Yes, there are difficulties with this scheme, but I think they are the same challenges as for implementing merges on a centralised VCS such as Subversion. I don't think there's anything insurmountable. Then a clone of a clone of a clone of a clone needs four clone numbers, plus a revision number. It'd look something like 5:1:2:1:1056. No. Just one repository number, and one revision number. You just need to be sensible in how the clone numbers are assigned. That's easy. Basically every repository has a number of clone numbers it can assign. Every clone gets a subset of that range. Dealing with the situation when the range has run out is a bit complicated, but quite doable, and there are steps you can take to make it a very rare occurence. I'm not have almost zero interest in this stuff, so I won't say any more. I'm really just commenting that it's not difficult to envisage an algorithm which makes exposing a random hash unnecessary.
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Bill Baxter wbax...@gmail.com wrote in message news:mailman.977.1296083661.4748.digitalmars-d-annou...@puremagic.com... Mercurial gives every revision two numbers: Is that the kind of thing you're wanting? Yea, and that's pretty much the original thing I was saying: It's nice that Hg seems to have it, but Git doesn't appear to be particularly interested in it.
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
On Thu, Jan 27, 2011 at 1:13 PM, Nick Sabalausky a@a.a wrote: Bill Baxter wbax...@gmail.com wrote in message news:mailman.977.1296083661.4748.digitalmars-d-annou...@puremagic.com... Mercurial gives every revision two numbers: Is that the kind of thing you're wanting? Yea, and that's pretty much the original thing I was saying: It's nice that Hg seems to have it, but Git doesn't appear to be particularly interested in it. I think it's very handy for all the reasons you said. I don't think I've every had to use a big hex string when dealing with mercurial. Maybe once or twice max. Most of the stuff you do with repo history as an individual developer is all about the local copy of the tree on your system. Globally unique identifiers aren't needed for that. It looks like Bzr does something similar. Not sure why Git hasn't gotten this particular nicety. --bb
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
Nick Sabalausky wrote: Bill Baxter wbax...@gmail.com wrote in message news:mailman.977.1296083661.4748.digitalmars-d-annou...@puremagic.com... Mercurial gives every revision two numbers: Is that the kind of thing you're wanting? Yea, and that's pretty much the original thing I was saying: It's nice that Hg seems to have it, but Git doesn't appear to be particularly interested in it. Of course, Git does not have it! Svn has it so it *must* be a bad idea ;) Jerome PS: FWIW, I agree with you. Plus, there is another use case where sequential number are very useful: each time you want to operate on a past revision in your own repository (e.g hg up n or hg diff -r n), it is much easier to designate that revision with a sequential number than with the hash. -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Nick Sabalausky Wrote: official public repo: r184 official public repo: r185 ...etc. Versus: 9f4e5ac4f0a3 13cf8da225ce ...etc. I don't know about other people, but I find the former to be far more readable, far more descriptive, and actually possible to reason about. Sure, the latter can be copy-pasted and it still refers to the same changeset, but other then that it's meaningless gibberish. LOL, this meaningless gibberish is usually called a unique identifier.
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
On Wed, 26 Jan 2011 06:33:35 +0200, Don nos...@nospam.com wrote: I think this is a fallacy. It only applies if you (1) *completely disallow* any centralisation -- which I don't think ever happens in practice! What about the Linux kernel? There's Linus's git repo, and lots of repos maintained by others (e.g. Linux distros). The other distros are not a superset of Linus's repo, they have their own branches with various project-specific patches and backports. Git was written for this specifically. and (2) demand that cloning a repository be an entirely read-only operation (so that the repository doesn't know how many times it has been cloned) and (3) demand that the revision numbers behave exactly as they do in svn. Then you're suggesting that the commit identifiers basically contain the clone history? -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
== Repost the article of Kagamin (s...@here.lot) == Posted at 2011/01/26 07:31 to digitalmars.D.announce Nick Sabalausky Wrote: official public repo: r184 official public repo: r185 ...etc. Versus: 9f4e5ac4f0a3 13cf8da225ce ...etc. I don't know about other people, but I find the former to be far more readable, far more descriptive, and actually possible to reason about. Sure, the latter can be copy-pasted and it still refers to the same changeset, but other then that it's meaningless gibberish. LOL, this meaningless gibberish is usually called a unique identifier. And I use git to download the source from github.com for druntime. But I found that in it subdirectory import, there is only contain std and object.di, missed the core subdirectory for druntime. Why? Or, the core subdirectory exists on the github.com, but we can no see it? or there have some other way except git to download it? waiting for kindly help. Best regards David.
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
On Wed, 26 Jan 2011 15:10:08 +0200, David Wang osx.da...@live.com wrote: And I use git to download the source from github.com for druntime. But I found that in it subdirectory import, there is only contain std and object.di, missed the core subdirectory for druntime. Why? Or, the core subdirectory exists on the github.com, but we can no see it? or there have some other way except git to download it? waiting for kindly help. Best regards David. The source code of druntime is under the src/core directory[1]. The .di files in the import directory are generated automatically during the build[2]. [1]: https://github.com/D-Programming-Language/druntime/tree/master/src/core [2]: https://github.com/D-Programming-Language/druntime/blob/master/win32.mak#L361 -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Nick Sabalausky Wrote: official public repo: r184 official public repo: r185 ...etc. Versus: 9f4e5ac4f0a3 13cf8da225ce ...etc. I don't know about other people, but I find the former to be far more readable, far more descriptive, and actually possible to reason about. Sure, the latter can be copy-pasted and it still refers to the same changeset, but other then that it's meaningless gibberish. A little example: today I commited changeset 35912, and 35780 - 10 day ago. Try to recall these random-looking numbers after reading a couple of posts in this NG.
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Kagamin s...@here.lot wrote in message news:ihpjji$115f$1...@digitalmars.com... Nick Sabalausky Wrote: official public repo: r184 official public repo: r185 ...etc. Versus: 9f4e5ac4f0a3 13cf8da225ce ...etc. I don't know about other people, but I find the former to be far more readable, far more descriptive, and actually possible to reason about. Sure, the latter can be copy-pasted and it still refers to the same changeset, but other then that it's meaningless gibberish. A little example: today I commited changeset 35912, and 35780 - 10 day ago. Try to recall these random-looking numbers after reading a couple of posts in this NG. 1. That's obviously a *lot* easier than 9f4e5ac4f0a3 and 13cf8da225ce 2. 35912 and 35780 are obviously related to each other in a certain way. I can tell just buy glancing that 35912 is a little over 100 commits after 35780. And I can immediately tell that they're both *far* newer than, say, 243. And far older than, say, 54928. Try doing that with hashes.
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Kagamin s...@here.lot wrote in message news:ihp46m$b3$1...@digitalmars.com... Nick Sabalausky Wrote: official public repo: r184 official public repo: r185 ...etc. Versus: 9f4e5ac4f0a3 13cf8da225ce ...etc. I don't know about other people, but I find the former to be far more readable, far more descriptive, and actually possible to reason about. Sure, the latter can be copy-pasted and it still refers to the same changeset, but other then that it's meaningless gibberish. LOL, this meaningless gibberish is usually called a unique identifier. I don't care what it's called. *Both* of the above examples are obviously unique. Repo name + revision number *does* uniquey identify one and only one changeset. Are you deliberately missing that point?
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
On Wed, 26 Jan 2011 22:43:11 +0200, Nick Sabalausky a@a.a wrote: 2. 35912 and 35780 are obviously related to each other in a certain way. I can tell just buy glancing that 35912 is a little over 100 commits after 35780. And I can immediately tell that they're both *far* newer than, say, 243. And far older than, say, 54928. Try doing that with hashes. None of these assertions hold in a DVCS repository. Merging in or rebasing an old branch ruins everything. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
On Wed, 26 Jan 2011 22:46:44 +0200, Nick Sabalausky a@a.a wrote: Are you deliberately missing that point? I think everyone's just annoyed how you're fiercely defending an idea that has a single advantage (terseness - I consider hashes unique in practice), but a whole slew of disadvantages, and then criticizing Git co. for being horrid because they don't use your idea. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
Vladimir Panteleev wrote: On Wed, 26 Jan 2011 06:33:35 +0200, Don nos...@nospam.com wrote: I think this is a fallacy. It only applies if you (1) *completely disallow* any centralisation -- which I don't think ever happens in practice! What about the Linux kernel? There's Linus's git repo, and lots of repos maintained by others (e.g. Linux distros). The other distros are not a superset of Linus's repo, they have their own branches with various project-specific patches and backports. Git was written for this specifically. Yes, but each distro has a trunk, in which all commits are ordered by time. There's always an official version of every branch. and (2) demand that cloning a repository be an entirely read-only operation (so that the repository doesn't know how many times it has been cloned) and (3) demand that the revision numbers behave exactly as they do in svn. Then you're suggesting that the commit identifiers basically contain the clone history? Yes, I think it could be done that way. Identifier would be composed of clonenumber+commitnumber. Where it is the location of the original change. Yes, there are difficulties with this scheme, but I think they are the same challenges as for implementing merges on a centralised VCS such as Subversion. I don't think there's anything insurmountable.
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
On Wed, 26 Jan 2011 23:36:03 +0200, Nick Sabalausky a@a.a wrote: Vladimir Panteleev vladi...@thecybershadow.net wrote in message news:op.vpxo9jz4tuz...@cybershadow.mshome.net... On Wed, 26 Jan 2011 22:43:11 +0200, Nick Sabalausky a@a.a wrote: 2. 35912 and 35780 are obviously related to each other in a certain way. I can tell just buy glancing that 35912 is a little over 100 commits after 35780. And I can immediately tell that they're both *far* newer than, say, 243. And far older than, say, 54928. Try doing that with hashes. None of these assertions hold in a DVCS repository. Merging in or rebasing an old branch ruins everything. I don't see how merging would cause a problem. A merge is a new commit, so it would get the next new revision number just like any other new commit would. Yes, but the commit numbers lose any meaning beyond the order in which the commits are added to the repository. That's barely useful, except when you know they're part of the same linear development history. And from what people have been saying, rebasing is only kosher on private repos so any little bit of awkwardness in there woudn't be a big deal (and I'm not sure how awkward it would be anyway since if if you're shuffling history around you'd *expect* the revision numbers to change since that's exactly what you're doing anyway). I meant non-destructive rebasing (not rewriting history), for example when backporting a feature, or when applying a feature branch on top of the latest master. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
On Wed, 26 Jan 2011 23:22:34 +0200, Don nos...@nospam.com wrote: Vladimir Panteleev wrote: On Wed, 26 Jan 2011 06:33:35 +0200, Don nos...@nospam.com wrote: I think this is a fallacy. It only applies if you (1) *completely disallow* any centralisation -- which I don't think ever happens in practice! What about the Linux kernel? There's Linus's git repo, and lots of repos maintained by others (e.g. Linux distros). The other distros are not a superset of Linus's repo, they have their own branches with various project-specific patches and backports. Git was written for this specifically. Yes, but each distro has a trunk, in which all commits are ordered by time. There's always an official version of every branch. Ordered by time of what? Time of merging into the branch? That's not very useful, is it? They can't be ordered by time of authorship, for certain. Official is technically meaningless in a DVCS, because no repository is holy by design (otherwise it wouldn't be really distributed). If the maintainer of a repository becomes MIA, anyone can take over without any problems. and (2) demand that cloning a repository be an entirely read-only operation (so that the repository doesn't know how many times it has been cloned) and (3) demand that the revision numbers behave exactly as they do in svn. Then you're suggesting that the commit identifiers basically contain the clone history? Yes, I think it could be done that way. Identifier would be composed of clonenumber+commitnumber. Where it is the location of the original change. Yes, there are difficulties with this scheme, but I think they are the same challenges as for implementing merges on a centralised VCS such as Subversion. I don't think there's anything insurmountable. Then a clone of a clone of a clone of a clone needs four clone numbers, plus a revision number. It'd look something like 5:1:2:1:1056. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Vladimir Panteleev vladi...@thecybershadow.net wrote in message news:op.vpxphnlmtuz...@cybershadow.mshome.net... On Wed, 26 Jan 2011 22:46:44 +0200, Nick Sabalausky a@a.a wrote: Are you deliberately missing that point? I think everyone's just annoyed how you're fiercely defending an idea that has a single advantage (terseness - I consider hashes unique in practice), but a whole slew of disadvantages, Terseness is not at all the only advantage. As I've said before, you can reason about them, compare them, and get a general idea of where they are in the history. I don't think merging or changing the past conflict with that. And I'm really not seeing any non-trivial disadvantages. and then criticizing Git co. for being horrid because they don't use your idea. What? Are you actually trying to claim that defending/promoting one's own idea when another idea exists is a *bad* thing? Seriously? If we're going to go that absurd route, I can just make up the claim people are ganging up on me for having an idea that just happens to be different from Git's world-view. If Git does something one way then that *must* be the best way, right? Anything else is obviously just heresy, right? Bring on the stakes and torches, we're going to Salem!!
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Vladimir Panteleev vladi...@thecybershadow.net wrote in message news:op.vpxqfimjtuz...@cybershadow.mshome.net... On Wed, 26 Jan 2011 23:36:03 +0200, Nick Sabalausky a@a.a wrote: Vladimir Panteleev vladi...@thecybershadow.net wrote in message news:op.vpxo9jz4tuz...@cybershadow.mshome.net... On Wed, 26 Jan 2011 22:43:11 +0200, Nick Sabalausky a@a.a wrote: 2. 35912 and 35780 are obviously related to each other in a certain way. I can tell just buy glancing that 35912 is a little over 100 commits after 35780. And I can immediately tell that they're both *far* newer than, say, 243. And far older than, say, 54928. Try doing that with hashes. None of these assertions hold in a DVCS repository. Merging in or rebasing an old branch ruins everything. I don't see how merging would cause a problem. A merge is a new commit, so it would get the next new revision number just like any other new commit would. Yes, but the commit numbers lose any meaning beyond the order in which the commits are added to the repository. That's barely useful, except when you know they're part of the same linear development history. It may not as meaningful as an SVN repo that never does any branching. But it's still much more meaningful than a hash. And from what people have been saying, rebasing is only kosher on private repos so any little bit of awkwardness in there woudn't be a big deal (and I'm not sure how awkward it would be anyway since if if you're shuffling history around you'd *expect* the revision numbers to change since that's exactly what you're doing anyway). I meant non-destructive rebasing (not rewriting history), for example when backporting a feature, or when applying a feature branch on top of the latest master. I guess I still don't see the problem there. It's still a new change that wasn't there before, hence a newly incremented revision number. And if it wants to add some meta-data referring to where it was copied over from, then ok.
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Vladimir Panteleev vladi...@thecybershadow.net wrote in message news:op.vpxqmbpftuz...@cybershadow.mshome.net... On Wed, 26 Jan 2011 23:22:34 +0200, Don nos...@nospam.com wrote: Vladimir Panteleev wrote: On Wed, 26 Jan 2011 06:33:35 +0200, Don nos...@nospam.com wrote: I think this is a fallacy. It only applies if you (1) *completely disallow* any centralisation -- which I don't think ever happens in practice! What about the Linux kernel? There's Linus's git repo, and lots of repos maintained by others (e.g. Linux distros). The other distros are not a superset of Linus's repo, they have their own branches with various project-specific patches and backports. Git was written for this specifically. Yes, but each distro has a trunk, in which all commits are ordered by time. There's always an official version of every branch. Ordered by time of what? Time of merging into the branch? That's not very useful, is it? Why wouldn't it be? It didn't exist in that branch befoe, and then it was added to that branch. Feature X was introduced in Version 2.31 and didn't exist in the 1.x line. But then Feature X was backported to the 1.x line at time Y / revision Y, which was right after we fixed 1.x's bug A and right before we fixed 1.x's bug B. What's wrong with that? Seems perfectly sensible to me.
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
On Wednesday, January 26, 2011 13:54:04 Nick Sabalausky wrote: Vladimir Panteleev vladi...@thecybershadow.net wrote in message news:op.vpxphnlmtuz...@cybershadow.mshome.net... On Wed, 26 Jan 2011 22:46:44 +0200, Nick Sabalausky a@a.a wrote: Are you deliberately missing that point? I think everyone's just annoyed how you're fiercely defending an idea that has a single advantage (terseness - I consider hashes unique in practice), but a whole slew of disadvantages, Terseness is not at all the only advantage. As I've said before, you can reason about them, compare them, and get a general idea of where they are in the history. I don't think merging or changing the past conflict with that. And I'm really not seeing any non-trivial disadvantages. and then criticizing Git co. for being horrid because they don't use your idea. What? Are you actually trying to claim that defending/promoting one's own idea when another idea exists is a *bad* thing? Seriously? If we're going to go that absurd route, I can just make up the claim people are ganging up on me for having an idea that just happens to be different from Git's world-view. If Git does something one way then that *must* be the best way, right? Anything else is obviously just heresy, right? Bring on the stakes and torches, we're going to Salem!! LOL. I think that part of what it comes down to is that you're making a big deal out of what other people don't consider to be a big deal at all. Personally, I don't care much about the revision number. Having incrementally increasing ones might be nice, but if you don't have them, oh well. Obviously, you feel much more strongly about it. Personally, I'm not about to claim that git does everything the best way possible, but I find it much more pleasant to deal with than svn. Other distributed VC systems may be better. There may be a better way that hasn't been found yet. I don't know. But I _do_ find git to be a major improvement over svn. - Jonathan M Davis
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.974.1296080574.4748.digitalmars-d-annou...@puremagic.com... On Wednesday, January 26, 2011 13:54:04 Nick Sabalausky wrote: Vladimir Panteleev vladi...@thecybershadow.net wrote in message news:op.vpxphnlmtuz...@cybershadow.mshome.net... On Wed, 26 Jan 2011 22:46:44 +0200, Nick Sabalausky a@a.a wrote: Are you deliberately missing that point? I think everyone's just annoyed how you're fiercely defending an idea that has a single advantage (terseness - I consider hashes unique in practice), but a whole slew of disadvantages, Terseness is not at all the only advantage. As I've said before, you can reason about them, compare them, and get a general idea of where they are in the history. I don't think merging or changing the past conflict with that. And I'm really not seeing any non-trivial disadvantages. and then criticizing Git co. for being horrid because they don't use your idea. What? Are you actually trying to claim that defending/promoting one's own idea when another idea exists is a *bad* thing? Seriously? If we're going to go that absurd route, I can just make up the claim people are ganging up on me for having an idea that just happens to be different from Git's world-view. If Git does something one way then that *must* be the best way, right? Anything else is obviously just heresy, right? Bring on the stakes and torches, we're going to Salem!! LOL. I think that part of what it comes down to is that you're making a big deal out of what other people don't consider to be a big deal at all. Heh, fair enough :) Personally, I don't care much about the revision number. Having incrementally increasing ones might be nice, but if you don't have them, oh well. Obviously, you feel much more strongly about it. I tend to be really bothered by steps backwards that I don't see as being necessary. Seems to be a common theme with me.
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Mercurial gives every revision two numbers: changeset: This field has the format of a number, followed by a colon, followed by a hexadecimal (or hex) string. These are identifiers for the changeset. The hex string is a unique identifier: the same hex string will always refer to the same changeset in every copy of this repository. The number is shorter and easier to type than the hex string, but it isn't unique: the same number in two different clones of a repository may identify different changesets. example-- changeset: 0:0a04b987be5a http://hgbook.red-bean.com/read/a-tour-of-mercurial-the-basics.html -- see section: A Tour Through History Is that the kind of thing you're wanting? --bb On Wed, Jan 26, 2011 at 2:37 PM, Nick Sabalausky a@a.a wrote: Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.974.1296080574.4748.digitalmars-d-annou...@puremagic.com... On Wednesday, January 26, 2011 13:54:04 Nick Sabalausky wrote: Vladimir Panteleev vladi...@thecybershadow.net wrote in message news:op.vpxphnlmtuz...@cybershadow.mshome.net... On Wed, 26 Jan 2011 22:46:44 +0200, Nick Sabalausky a@a.a wrote: Are you deliberately missing that point? I think everyone's just annoyed how you're fiercely defending an idea that has a single advantage (terseness - I consider hashes unique in practice), but a whole slew of disadvantages, Terseness is not at all the only advantage. As I've said before, you can reason about them, compare them, and get a general idea of where they are in the history. I don't think merging or changing the past conflict with that. And I'm really not seeing any non-trivial disadvantages. and then criticizing Git co. for being horrid because they don't use your idea. What? Are you actually trying to claim that defending/promoting one's own idea when another idea exists is a *bad* thing? Seriously? If we're going to go that absurd route, I can just make up the claim people are ganging up on me for having an idea that just happens to be different from Git's world-view. If Git does something one way then that *must* be the best way, right? Anything else is obviously just heresy, right? Bring on the stakes and torches, we're going to Salem!! LOL. I think that part of what it comes down to is that you're making a big deal out of what other people don't consider to be a big deal at all. Heh, fair enough :) Personally, I don't care much about the revision number. Having incrementally increasing ones might be nice, but if you don't have them, oh well. Obviously, you feel much more strongly about it. I tend to be really bothered by steps backwards that I don't see as being necessary. Seems to be a common theme with me.
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Nick Sabalausky wrote:
David Nadlinger s...@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
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Lutger Blijdestijn lutger.blijdest...@gmail.com wrote in message
news:ihn21d$2esd$1...@digitalmars.com...
Nick Sabalausky wrote:
David Nadlinger s...@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.
Obviously I'm not saying DMD should have gone Hg, I'm just kinda shocked
by how horrid Git's approach is for referring to changesets. (Personally,
that alone would be enough to get me to use Hg instead of Git for my own
projects. Heck, I've become pretty much sold on the idea of DVCS, but
because of this I think I'd actually sooner use SVN for a new project than
Git.)
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Nick Sabalausky a@a.a wrote in message
news:ihne76$4cp$1...@digitalmars.com...
Lutger Blijdestijn lutger.blijdest...@gmail.com wrote in message
news:ihn21d$2esd$1...@digitalmars.com...
Nick Sabalausky wrote:
David Nadlinger s...@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.
Obviously I'm not saying DMD should have gone Hg, I'm just kinda shocked
by how horrid Git's approach is for referring to changesets. (Personally,
that alone would be enough to get me to use Hg instead of Git for my own
projects. Heck, I've become pretty much sold on the idea of DVCS, but
because of this I think I'd actually sooner use SVN for a new project than
Git.)
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.
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
On Tue, 25 Jan 2011 23:08:13 +0200, Nick Sabalausky a@a.a wrote: 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. 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. Obviously I'm not saying DMD should have gone Hg, I'm just kinda shocked by how horrid Git's approach is for referring to changesets. (Personally, that alone would be enough to get me to use Hg instead of Git for my own projects. Heck, I've become pretty much sold on the idea of DVCS, but because of this I think I'd actually sooner use SVN for a new project than Git.) I think you need to take some time and think about it. It's impossible to use a global incrementing revision number with any DVCS! In fact, I dare to think that Hg having revision numbers is a stupid mistake that tries to make SVN users comfy, but will only lead to confusion and angst when people try to refer to revisions by their number. 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? Also, saying that SHA-1 hash collisions are very rare is a bit of an understatement. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Nick Sabalausky wrote:
Lutger Blijdestijn lutger.blijdest...@gmail.com wrote in message
news:ihn21d$2esd$1...@digitalmars.com...
Nick Sabalausky wrote:
David Nadlinger s...@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
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. You can't expect other people to piece together how the
revision number has come to be, that is extremely brittle.
Obviously I'm not saying DMD should have gone Hg, I'm just kinda shocked
by how horrid Git's approach is for referring to changesets. (Personally,
that alone would be enough to get me to use Hg instead of Git for my own
projects. Heck, I've become pretty much sold on the idea of DVCS, but
because of this I think I'd actually sooner use SVN for a new project than
Git.)
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Vladimir Panteleev vladi...@thecybershadow.net wrote in message news:op.vpvv5sn8tuz...@cybershadow.mshome.net... On Tue, 25 Jan 2011 23:08:13 +0200, Nick Sabalausky a@a.a wrote: 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. Not just what repository, but what clone of the repository! 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. 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. Yea, that's what I was looking at. The numbers for a *local* repository aren't really usable by anyone else since no one else has access to it. But it's extremely rare not to have at least one *common* repository that everyone pushes/pulls to. I see no reason why the numbers of those common repositories can't be used among multiple people, again, providing that it's understood which repository is being talked about. Obviously I'm not saying DMD should have gone Hg, I'm just kinda shocked by how horrid Git's approach is for referring to changesets. (Personally, that alone would be enough to get me to use Hg instead of Git for my own projects. Heck, I've become pretty much sold on the idea of DVCS, but because of this I think I'd actually sooner use SVN for a new project than Git.) I think you need to take some time and think about it. It's impossible to use a global incrementing revision number with any DVCS! 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)** In fact, I dare to think that Hg having revision numbers is a stupid mistake that tries to make SVN users comfy, but will only lead to confusion and angst when people try to refer to revisions by their number. There are plenty of things about *any* DVCS that are going to confuse people who try to treat it like SVN. If that was a valid reason not to do something a certain way, then Hg/Git/etc would all have to *be* SVN. 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. 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.
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
On 25/01/11 21:08, Nick Sabalausky wrote:
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.
Obviously I'm not saying DMD should have gone Hg, I'm just kinda shocked
by how horrid Git's approach is for referring to changesets. (Personally,
that alone would be enough to get me to use Hg instead of Git for my own
projects. Heck, I've become pretty much sold on the idea of DVCS, but
because of this I think I'd actually sooner use SVN for a new project than
Git.)
This is the primary reason I use hg over git (that and I find it far
easier to use, but that's debatable, I know loads of people that find
git easier to use - guess it depends on your mindset).
For all the nay-sayers to numbers in revisions - unless you're working
on huge projects with lots of developers, for the most part all the devs
will have the same revision numbers. Sure, it's completely flawed, but
even when you get to the stage where nice base-10 numbers aren't
feasible due to all the developers having different local repositories
it's still useful. In hg you'll see something like '70:5abed7016f34' -
you get a rough idea where it is automatically from the number, and can
look up the exact revision if you need to. It's also great for
technically inclined beta testers - their revision numbers will be in
sync with the repository as it's highly unlikely they'll have their own
changes.
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
--
Robert
http://octarineparrot.com/
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Lutger Blijdestijn lutger.blijdest...@gmail.com wrote in message
news:ihnh65$ak4$1...@digitalmars.com...
Nick Sabalausky wrote:
Lutger Blijdestijn lutger.blijdest...@gmail.com wrote in message
news:ihn21d$2esd$1...@digitalmars.com...
Nick Sabalausky wrote:
David Nadlinger s...@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.
.
.
.
.
.
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.
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!
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
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/
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/
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/
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Lutger Blijdestijn lutger.blijdest...@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.
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 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?)
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
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.
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Ulrik Mikaelsson ulrik.mikaels...@gmail.com wrote in message news:mailman.949.1295999711.4748.digitalmars-d-annou...@puremagic.com... Again, version-number + repo is not 100% when history-rewrite is possible. History-rewrite is new to me. Does that just mean branching off from a past revision? If not, do you have a link that explains it?
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
Robert Clipsham wrote: You have much to learn young Padawan! May the source be with you. ^^ Fixed that for you.
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
On Tuesday, January 25, 2011 16:50:03 Nick Sabalausky wrote: Ulrik Mikaelsson ulrik.mikaels...@gmail.com wrote in message news:mailman.949.1295999711.4748.digitalmars-d-annou...@puremagic.com... Again, version-number + repo is not 100% when history-rewrite is possible. History-rewrite is new to me. Does that just mean branching off from a past revision? If not, do you have a link that explains it? You can do stuff like re-order and squash commits. Look at the man page for git- rebase. - Jonathan M Davis
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
On Wed, 26 Jan 2011 00:28:22 +0200, Nick Sabalausky a@a.a wrote: 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. OK, I see your point. However, I would avoid using such a way to refer to commits, where mistaking one half of it may still point towards a commit, however a completely unrelated one. But it's extremely rare not to have at least one *common* repository that everyone pushes/pulls to. Um, why do you think people wrote DVCS systems? They could have just souped up SVN with local commits and proper merging etc. (I heard SVN was going to do that anyway.) I don't understand why you think I'm claiming anything of the sort. I was under the impression you thought commit numbers somehow magically propagated themselves throughout all clones of the repository (distinct repository was ambiguous), since I saw no point in referring to a revision number that's only valid for the copy on your hard drive. I didn't think you implied the scenario of making your repository remotely accessible. There are plenty of things about *any* DVCS that are going to confuse people who try to treat it like SVN. If that was a valid reason not to do something a certain way, then Hg/Git/etc would all have to *be* SVN. An analogy to this mis-feature would be D compiling valid C code in a subtly different manner than C. D explicitly avoids this, with good reason. 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. I think you're more likely to simultaneously get hit by a lightning and crushed by a falling airplane during an earthquake than encountering a hash collision in your repository. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.950.1296005459.4748.digitalmars-d-annou...@puremagic.com... On Tuesday, January 25, 2011 16:50:03 Nick Sabalausky wrote: Ulrik Mikaelsson ulrik.mikaels...@gmail.com wrote in message news:mailman.949.1295999711.4748.digitalmars-d-annou...@puremagic.com... Again, version-number + repo is not 100% when history-rewrite is possible. History-rewrite is new to me. Does that just mean branching off from a past revision? If not, do you have a link that explains it? You can do stuff like re-order and squash commits. Look at the man page for git- rebase. Ok, I just took a look at it here: http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html Maybe it's just my inexperience with DVCSes, but everything in there seems like the sort of thing I would consider much better off accomplished by just simply creating a new branch that re-applies changesets from an existing branch (or in most cases of removing changesets, committing a new changeset that undoes the undesired ones) instead of screwing around with the history. And if some joker's been spamming a repo with a bunch of garbage commits, then ok, maybe have something to delete that old junk branch. But aside from that sort of special case, I don't see what good can come from encouraging removal of the old branch versus just simply adding a new one or committing an undo changeset. In other words, history-rewriting seems to trade in the reliability of a stable history for...apperently some benefit that I'm having trouble seeing (Just so that you can? I kinda doubt that would be the reason though, especially if Torvalds is heavily involved.) Ulrick mentioned that history rewriting is encouraged under some particular circumstances. What circumstances would those be?
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Vladimir Panteleev vladi...@thecybershadow.net wrote in message news:op.vpv8w0pctuz...@cybershadow.mshome.net... On Wed, 26 Jan 2011 00:28:22 +0200, Nick Sabalausky a@a.a wrote: I don't understand why you think I'm claiming anything of the sort. I was under the impression you thought commit numbers somehow magically propagated themselves throughout all clones of the repository (distinct repository was ambiguous), since I saw no point in referring to a revision number that's only valid for the copy on your hard drive. I didn't think you implied the scenario of making your repository remotely accessible. Well, normally there's at least *some* repository that's remotely accessible, otherwise nobody would (or even could) be doing any cloning or pulling or pushing (and you'd be left with a single-user private SVN with better merging). I agree that referring to a revision number that's only valid on your own local repo is of questionable benefit if it's not remotely accessible. However, I do think it makes sense to refer to a revision number on whatever remotely accessible repo inevitably does exist.
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
On Tuesday 25 January 2011 18:24:56 Nick Sabalausky wrote: Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.950.1296005459.4748.digitalmars-d-annou...@puremagic.com... On Tuesday, January 25, 2011 16:50:03 Nick Sabalausky wrote: Ulrik Mikaelsson ulrik.mikaels...@gmail.com wrote in message news:mailman.949.1295999711.4748.digitalmars-d-annou...@puremagic.com... Again, version-number + repo is not 100% when history-rewrite is possible. History-rewrite is new to me. Does that just mean branching off from a past revision? If not, do you have a link that explains it? You can do stuff like re-order and squash commits. Look at the man page for git- rebase. Ok, I just took a look at it here: http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html Maybe it's just my inexperience with DVCSes, but everything in there seems like the sort of thing I would consider much better off accomplished by just simply creating a new branch that re-applies changesets from an existing branch (or in most cases of removing changesets, committing a new changeset that undoes the undesired ones) instead of screwing around with the history. And if some joker's been spamming a repo with a bunch of garbage commits, then ok, maybe have something to delete that old junk branch. But aside from that sort of special case, I don't see what good can come from encouraging removal of the old branch versus just simply adding a new one or committing an undo changeset. In other words, history-rewriting seems to trade in the reliability of a stable history for...apperently some benefit that I'm having trouble seeing (Just so that you can? I kinda doubt that would be the reason though, especially if Torvalds is heavily involved.) Ulrick mentioned that history rewriting is encouraged under some particular circumstances. What circumstances would those be? I don't know how encouraged it is or isn't. The way I use it most often is to do multiple small commits as I'm working on something and then squash them into one when I'm done. I could also see circumstances where it would be advantageous to reorder some commits - particularly if you wanted to create a branch with some of the newer changesets but not some of the ones just prior to them. So, I think that it's a highly useful feature. Still, beyond squashing multiple smaller commits together when I'm done working on something, I don't see a whole lot of value in using rebase regularly. Perhaps there's a good reason for it that I'm not aware of though. Regardless, rebasing changes the tree, resulting in new SHA1 hashes for each commit, so it's not like you can screw up a repository without anyone who has branched off from it noticing. So, I'm not sure how abusable it really is on anything other than a one man project. So, while I can understand why rebase could be considered a potential problem, I think that it's well worth having. Still, I don't really know what the encouraged under some particular circumstances would be referring to. - Jonathan M Davis
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
On Wed, 26 Jan 2011 04:24:56 +0200, Nick Sabalausky a@a.a wrote: Maybe it's just my inexperience with DVCSes, but everything in there seems like the sort of thing I would consider much better off accomplished by just simply creating a new branch that re-applies changesets from an existing branch (or in most cases of removing changesets, committing a new changeset that undoes the undesired ones) instead of screwing around with the history. History rewriting in public repositories is very rare. It's a hassle for everyone - if someone forked off the rewritten branch, they'll need to rebase that branch on the new one. However, history rewriting can be extremely useful for local commits. Here are a few typical use cases: 1) You made a typo in a commit message a few commits ago. 2) You wish to fix something in a local commit from a while ago. This can be done by editing the commit directly (as above), or by making the fix as a new commit, an merging the two commits together. 3) You wish to clean up and reorder your development history into atomic commits, ready to be sent upstream as a patchset (very common with open-source projects). 4) You wish to split a subdirectory of the repository, along with all of its history, to a separate repository. etc. git provides many ways of automating common history edits - see the man page for git-filter-branch, for some examples. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
On Wed, 26 Jan 2011 04:40:03 +0200, Nick Sabalausky a@a.a wrote: Well, normally there's at least *some* repository that's remotely accessible, otherwise nobody would (or even could) be doing any cloning or pulling or pushing (and you'd be left with a single-user private SVN with better merging). Thus the question is - does Hg even allow you to (easily) inspect revision numbers of an arbitrary remote repository? Are they preserved while cloning? Also, how would you look up the revision number of a specific commit in another repository? By its hash? Why not just give other people the hash directly? :) -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Vladimir Panteleev vladi...@thecybershadow.net wrote in message news:op.vpwb01qttuz...@cybershadow.mshome.net... On Wed, 26 Jan 2011 04:24:56 +0200, Nick Sabalausky a@a.a wrote: Maybe it's just my inexperience with DVCSes, but everything in there seems like the sort of thing I would consider much better off accomplished by just simply creating a new branch that re-applies changesets from an existing branch (or in most cases of removing changesets, committing a new changeset that undoes the undesired ones) instead of screwing around with the history. History rewriting in public repositories is very rare. It's a hassle for everyone - if someone forked off the rewritten branch, they'll need to rebase that branch on the new one. However, history rewriting can be extremely useful for local commits. Here are a few typical use cases: 1) You made a typo in a commit message a few commits ago. 2) You wish to fix something in a local commit from a while ago. This can be done by editing the commit directly (as above), or by making the fix as a new commit, an merging the two commits together. 3) You wish to clean up and reorder your development history into atomic commits, ready to be sent upstream as a patchset (very common with open-source projects). 4) You wish to split a subdirectory of the repository, along with all of its history, to a separate repository. etc. git provides many ways of automating common history edits - see the man page for git-filter-branch, for some examples. Ahh, I see. That does sound useful then. But that does mean that any implications that would have on an incremented changeset number shouldn't be a problem in practice since it's mainly just done on private repos.
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Vladimir Panteleev vladi...@thecybershadow.net wrote in message news:op.vpwco52etuz...@cybershadow.mshome.net... On Wed, 26 Jan 2011 04:40:03 +0200, Nick Sabalausky a@a.a wrote: Well, normally there's at least *some* repository that's remotely accessible, otherwise nobody would (or even could) be doing any cloning or pulling or pushing (and you'd be left with a single-user private SVN with better merging). Thus the question is - does Hg even allow you to (easily) inspect revision numbers of an arbitrary remote repository? Yes. Exhibits A, B and C: - Joel's HgInit: http://hginit.com/01.html (Do a text-search inside the page for changeset:) - Trac's Hg browser: http://www.dsource.org/projects/ddmd/browser - Hg's built-in html browser: http://hg.dsource.org/projects/ddmd/rev/13cf8da225ce It seems to be typical convention in the Hg world for changesets to be displayed in the format revision:hash. I would imagine you could use either one by itself to refer to a specific commit (don't know for certain though, haven't used it enough). Are they preserved while cloning? Maybe someone with real Hg experience could answer this. I'd be surprised if the answer is no, since it is supposed to be a clone after all, but I really don't know. Also, how would you look up the revision number of a specific commit in another repository? By its hash? Not sure what you mean. A commit in a given repo has both a revision number and a hash so I'd image you could use either one to look up the other. If you mean that you have a revision number in your local repo and want to find the revision number of the same changeset in a remote repo, then yes, you would have to use the hash as a go-between. But I see no technical reason why it shouldn't be possible for that to entirely do-able behind-the-scenes as long as there's a way to specify a specific remote repository. Whether or not Hg currently has such an automatic ability, I have no idea. Why not just give other people the hash directly? :) official public repo: r184 official public repo: r185 ...etc. Versus: 9f4e5ac4f0a3 13cf8da225ce ...etc. I don't know about other people, but I find the former to be far more readable, far more descriptive, and actually possible to reason about. Sure, the latter can be copy-pasted and it still refers to the same changeset, but other then that it's meaningless gibberish.
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
As far as I can tell hg stores both a commit number and a hash, e.g.: D:\dev\projects\projecthg log -r : changeset: 0:08d729df85c9 user:Andrej Mitrovic andrej.mitrov...@gmail.com date:Fri Dec 22 00:07:02 2010 +0200 summary: bla bla changeset: 1:61cfebefee15 user:Andrej Mitrovic andrej.mitrov...@gmail.com date:Fri Dec 24 21:42:45 2010 +0100 summary: bla bla I don't know the details, I've just started using hg recently.
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
Vladimir Panteleev wrote: On Tue, 25 Jan 2011 23:08:13 +0200, Nick Sabalausky a@a.a wrote: 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. 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. Obviously I'm not saying DMD should have gone Hg, I'm just kinda shocked by how horrid Git's approach is for referring to changesets. (Personally, that alone would be enough to get me to use Hg instead of Git for my own projects. Heck, I've become pretty much sold on the idea of DVCS, but because of this I think I'd actually sooner use SVN for a new project than Git.) I think you need to take some time and think about it. It's impossible to use a global incrementing revision number with any DVCS! I think this is a fallacy. It only applies if you (1) *completely disallow* any centralisation -- which I don't think ever happens in practice! and (2) demand that cloning a repository be an entirely read-only operation (so that the repository doesn't know how many times it has been cloned) and (3) demand that the revision numbers behave exactly as they do in svn. The SHA1 hashes are how many bits??? Enough for one commit from every person on earth, every few minutes, for hundreds of years That's a ridiculously inefficient method of identifying changesets. Looks like a strawman argument to me. It can't be done, but only because unnecessary requirements have been added.
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
On Tuesday 25 January 2011 20:33:35 Don wrote: Vladimir Panteleev wrote: On Tue, 25 Jan 2011 23:08:13 +0200, Nick Sabalausky a@a.a wrote: 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. 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. Obviously I'm not saying DMD should have gone Hg, I'm just kinda shocked by how horrid Git's approach is for referring to changesets. (Personally, that alone would be enough to get me to use Hg instead of Git for my own projects. Heck, I've become pretty much sold on the idea of DVCS, but because of this I think I'd actually sooner use SVN for a new project than Git.) I think you need to take some time and think about it. It's impossible to use a global incrementing revision number with any DVCS! I think this is a fallacy. It only applies if you (1) *completely disallow* any centralisation -- which I don't think ever happens in practice! and (2) demand that cloning a repository be an entirely read-only operation (so that the repository doesn't know how many times it has been cloned) and (3) demand that the revision numbers behave exactly as they do in svn. The SHA1 hashes are how many bits??? Enough for one commit from every person on earth, every few minutes, for hundreds of years That's a ridiculously inefficient method of identifying changesets. Looks like a strawman argument to me. It can't be done, but only because unnecessary requirements have been added. The main reason for the SHA1 is to verify that the repository hasn't been tampered with or corrupted. I suspect that Linus decided to just use it as the identifier for the changeset, because then you only have one number to worry about, not two (the hash and the changeset number). And given the difficulties with regards to incremental revision numbers in a distributed VCS (particularly one which allows for changes to the revision history), I can understand deciding to just not bother with them. Whether that was the best decision or not is another matter. Regardless, I don't think that SHA1 was picked as a changeset ID because of how many revision numbers it can hold. - Jonathan M Davis
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
On Monday 24 January 2011 01:29:33 Jacob Carlborg wrote: On 2011-01-24 05:26, Walter Bright wrote: https://github.com/organizations/D-Programming-Language We're all learning how to use github, but by most accounts it seems to be the best available system for the diverse group of people who work on it. Are we supposed to be able to access this repository? When I enter the address in the web browser it redirects to the github start page. If I try to clone it I get this error: fatal: https://github.com/organizations/D-Programming-Language /info/refs not found: did you run git update-server-info on the server? That links to the organization D-Programming-Language on github. https://github.com/D-Programming-Language is the link to the list of repositories. You'll need to go the individual repository for a project to find the URL to use to clone that repository. - Jonathan M Davis
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
On 2011-01-24 10:35, Jonathan M Davis wrote: On Monday 24 January 2011 01:29:33 Jacob Carlborg wrote: On 2011-01-24 05:26, Walter Bright wrote: https://github.com/organizations/D-Programming-Language We're all learning how to use github, but by most accounts it seems to be the best available system for the diverse group of people who work on it. Are we supposed to be able to access this repository? When I enter the address in the web browser it redirects to the github start page. If I try to clone it I get this error: fatal: https://github.com/organizations/D-Programming-Language /info/refs not found: did you run git update-server-info on the server? That links to the organization D-Programming-Language on github. https://github.com/D-Programming-Language is the link to the list of repositories. You'll need to go the individual repository for a project to find the URL to use to clone that repository. - Jonathan M Davis Ahh, I see. -- /Jacob Carlborg
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
On 2011-01-24 05:26, Walter Bright wrote: https://github.com/organizations/D-Programming-Language We're all learning how to use github, but by most accounts it seems to be the best available system for the diverse group of people who work on it. BTW, what about the backend in the DMD repository. Is is ok now to just fork the repository? -- /Jacob Carlborg
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
On 2011-01-24 07:52:24 -0500, Jacob Carlborg d...@me.com said: On 2011-01-24 05:26, Walter Bright wrote: https://github.com/organizations/D-Programming-Language We're all learning how to use github, but by most accounts it seems to be the best available system for the diverse group of people who work on it. BTW, what about the backend in the DMD repository. Is is ok now to just fork the repository? There's a big inviting 'Fork' button for that at the top of each page which duplicates the repository in your own account (without any warning I might add). So whether it's okay or not, I'm pretty sure most people who do not closely read the license will assume it is. A Github free account is meant for 'open-source' projects after all. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Walter Bright wrote: David Wang wrote: Dear Walter, I went to the github and try to download the source, I found that the latest version on github is the old version. for example: druntime - Downloads: dmd-2.042 Phobos - Downloads: phobos-2.046 DMD - Downloads: dmd-2.046 I think the actural latest version of D should be 2.051. Why github can not showing the 2.051 version(dmd, phobos, druntime, and so on.) ? I think it is because the tags were never done properly on svn, either. It's still possible to add the tags (see http://progit.org/book/ch2-6.html Tagging Later) but we'd have to know the commits used for the releases. I guess there's no easy way to figure out which commits were used for the releases? -- Johannes Pfau signature.asc Description: PGP signature
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
On Mon, 24 Jan 2011 09:00:21 -0500, Johannes Pfau s...@example.com wrote: Walter Bright wrote: David Wang wrote: Dear Walter, I went to the github and try to download the source, I found that the latest version on github is the old version. for example: druntime - Downloads: dmd-2.042 Phobos - Downloads: phobos-2.046 DMD - Downloads: dmd-2.046 I think the actural latest version of D should be 2.051. Why github can not showing the 2.051 version(dmd, phobos, druntime, and so on.) ? I think it is because the tags were never done properly on svn, either. It's still possible to add the tags (see http://progit.org/book/ch2-6.html Tagging Later) but we'd have to know the commits used for the releases. I guess there's no easy way to figure out which commits were used for the releases? All source is included in the compiler. It's simply a matter of doing a directory compare of the code against source control. The date released should narrow it down to a manageable level. I have done it in the past (http://www.dsource.org/projects/druntime/changeset/272) In fact, it looks like I was the last one to tag druntime :) Some script-fu could probably fill in all the holes automatically... -Steve
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Steven Schveighoffer wrote: On Mon, 24 Jan 2011 09:00:21 -0500, Johannes Pfau s...@example.com wrote: Walter Bright wrote: David Wang wrote: Dear Walter, I went to the github and try to download the source, I found that the latest version on github is the old version. for example: druntime - Downloads: dmd-2.042 Phobos - Downloads: phobos-2.046 DMD - Downloads: dmd-2.046 I think the actural latest version of D should be 2.051. Why github can not showing the 2.051 version(dmd, phobos, druntime, and so on.) ? I think it is because the tags were never done properly on svn, either. It's still possible to add the tags (see http://progit.org/book/ch2-6.html Tagging Later) but we'd have to know the commits used for the releases. I guess there's no easy way to figure out which commits were used for the releases? All source is included in the compiler. It's simply a matter of doing a directory compare of the code against source control. The date released should narrow it down to a manageable level. I have done it in the past (http://www.dsource.org/projects/druntime/changeset/272) In fact, it looks like I was the last one to tag druntime :) Some script-fu could probably fill in all the holes automatically... -Steve OK, here are some revisions: DMD: 2.051 seems to be revision 1374ba96fa5516d9595fa61b09015197a8b84385 Note: The changelog on the website says release date Nov 7 but it's more like 20th December. Note2: The git repository contains a object.h file in that revision which isn't in the dmd zip. 2.050 50fb3d60811b203ac50a0d9169bf15a28881c9b5 Note: The git repository contains a argtypes.c file in that revision which isn't in the dmd zip. 2.049 ab38d58ecb78924d631f7f77863fff2a6c234eb6 2.048 bcf720fe079fd979fa9e81f63ab2de3dde9284dc 2.047 ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48 Note: In the dmd zip, there are 7 additional lines in root/root.c. Those were later added to the repository, but ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48 seems to be the correct commit. -- Johannes Pfau signature.asc Description: PGP signature
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
On Mon, 24 Jan 2011 10:34:18 -0500, Johannes Pfau s...@example.com wrote: Steven Schveighoffer wrote: On Mon, 24 Jan 2011 09:00:21 -0500, Johannes Pfau s...@example.com wrote: Walter Bright wrote: David Wang wrote: Dear Walter, I went to the github and try to download the source, I found that the latest version on github is the old version. for example: druntime - Downloads: dmd-2.042 Phobos - Downloads: phobos-2.046 DMD - Downloads: dmd-2.046 I think the actural latest version of D should be 2.051. Why github can not showing the 2.051 version(dmd, phobos, druntime, and so on.) ? I think it is because the tags were never done properly on svn, either. It's still possible to add the tags (see http://progit.org/book/ch2-6.html Tagging Later) but we'd have to know the commits used for the releases. I guess there's no easy way to figure out which commits were used for the releases? All source is included in the compiler. It's simply a matter of doing a directory compare of the code against source control. The date released should narrow it down to a manageable level. I have done it in the past (http://www.dsource.org/projects/druntime/changeset/272) In fact, it looks like I was the last one to tag druntime :) Some script-fu could probably fill in all the holes automatically... -Steve OK, here are some revisions: DMD: 2.051 seems to be revision 1374ba96fa5516d9595fa61b09015197a8b84385 Note: The changelog on the website says release date Nov 7 but it's more like 20th December. That is probably a doc bug. When creating the 'next' version in the changelog, Walter arbitrarily puts a date in there as a placeholder (usually the date he does that), and looks like he forgot to change it. Probably we should get into the practice of putting TBD instead of a date. Note2: The git repository contains a object.h file in that revision which isn't in the dmd zip. 2.050 50fb3d60811b203ac50a0d9169bf15a28881c9b5 Note: The git repository contains a argtypes.c file in that revision which isn't in the dmd zip. 2.049 ab38d58ecb78924d631f7f77863fff2a6c234eb6 2.048 bcf720fe079fd979fa9e81f63ab2de3dde9284dc 2.047 ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48 Note: In the dmd zip, there are 7 additional lines in root/root.c. Those were later added to the repository, but ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48 seems to be the correct commit. At this point, I would say, tag those versions. Its very unlikely that someone ever needs one of these old revs anyways. I'm glad you were able to do all this work, thanks! -Steve
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Johannes Pfau s...@example.com wrote in message news:20110124163418.3880a154@jpf-Satellite-A100... OK, here are some revisions: DMD: 2.051 seems to be revision 1374ba96fa5516d9595fa61b09015197a8b84385 Note: The changelog on the website says release date Nov 7 but it's more like 20th December. Note2: The git repository contains a object.h file in that revision which isn't in the dmd zip. 2.050 50fb3d60811b203ac50a0d9169bf15a28881c9b5 Note: The git repository contains a argtypes.c file in that revision which isn't in the dmd zip. 2.049 ab38d58ecb78924d631f7f77863fff2a6c234eb6 2.048 bcf720fe079fd979fa9e81f63ab2de3dde9284dc 2.047 ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48 Note: In the dmd zip, there are 7 additional lines in root/root.c. Those were later added to the repository, but ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48 seems to be the correct commit. Does Git really not have real revision/changeset numbers?
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.911.1295903507.4748.digitalmars-d-annou...@puremagic.com... On Monday 24 January 2011 13:04:27 Nick Sabalausky wrote: Johannes Pfau s...@example.com wrote in message news:20110124163418.3880a154@jpf-Satellite-A100... OK, here are some revisions: DMD: 2.051 seems to be revision 1374ba96fa5516d9595fa61b09015197a8b84385 Note: The changelog on the website says release date Nov 7 but it's more like 20th December. Note2: The git repository contains a object.h file in that revision which isn't in the dmd zip. 2.050 50fb3d60811b203ac50a0d9169bf15a28881c9b5 Note: The git repository contains a argtypes.c file in that revision which isn't in the dmd zip. 2.049 ab38d58ecb78924d631f7f77863fff2a6c234eb6 2.048 bcf720fe079fd979fa9e81f63ab2de3dde9284dc 2.047 ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48 Note: In the dmd zip, there are 7 additional lines in root/root.c. Those were later added to the repository, but ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48 seems to be the correct commit. Does Git really not have real revision/changeset numbers? It's SHA1 hashes. And actually, considering how prevalent branching and merging is with git (_everyone_ has their own fork of the repository), I question that revision/changeset numbers would work anyway. The fact that you can reorder commits wouldn't help either. So, no. Git doesn't have revision or changeset numbers. However, the git commands where you give it a revision's SHA1 only need enough of the SHA1 to uniquely identify it, so you rarely need to type the whole thing even when you're giving it the SHA1. Now, I suppose that makes things like the revision number for dmd 2.049 uglier, but git is very much distributed and not centralized in terms of how it's set up, so revision numbers in the SVN sense just wouldn't make sense. 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.
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
On Monday, January 24, 2011 13:20:44 Nick Sabalausky wrote: Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.911.1295903507.4748.digitalmars-d-annou...@puremagic.com... On Monday 24 January 2011 13:04:27 Nick Sabalausky wrote: Johannes Pfau s...@example.com wrote in message news:20110124163418.3880a154@jpf-Satellite-A100... OK, here are some revisions: DMD: 2.051 seems to be revision 1374ba96fa5516d9595fa61b09015197a8b84385 Note: The changelog on the website says release date Nov 7 but it's more like 20th December. Note2: The git repository contains a object.h file in that revision which isn't in the dmd zip. 2.050 50fb3d60811b203ac50a0d9169bf15a28881c9b5 Note: The git repository contains a argtypes.c file in that revision which isn't in the dmd zip. 2.049 ab38d58ecb78924d631f7f77863fff2a6c234eb6 2.048 bcf720fe079fd979fa9e81f63ab2de3dde9284dc 2.047 ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48 Note: In the dmd zip, there are 7 additional lines in root/root.c. Those were later added to the repository, but ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48 seems to be the correct commit. Does Git really not have real revision/changeset numbers? It's SHA1 hashes. And actually, considering how prevalent branching and merging is with git (_everyone_ has their own fork of the repository), I question that revision/changeset numbers would work anyway. The fact that you can reorder commits wouldn't help either. So, no. Git doesn't have revision or changeset numbers. However, the git commands where you give it a revision's SHA1 only need enough of the SHA1 to uniquely identify it, so you rarely need to type the whole thing even when you're giving it the SHA1. Now, I suppose that makes things like the revision number for dmd 2.049 uglier, but git is very much distributed and not centralized in terms of how it's set up, so revision numbers in the SVN sense just wouldn't make sense. 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. I don't know. I haven't used Hg. However, I have a hard time seeing how you could have revision numbers like subversion does. You could certainly have numbers which weren't hashes or in base 16, but you can't just increment the version number each time, or you'll run into conflicts when you go to merge. Maybe the Hg guys figured out something smart that manages. I don't know. But git uses the SHA1 hash, which is supposedly unique and avoids any version numbers clashing. It also serves as a means of guaranteeing that your repository hasn't been damaged, since if the repo's state doesn't match its SHA1, then it's not valid (due to data corruption or tampering or whatever). - Jonathan M Davis
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Nick Sabalausky Wrote: 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. Here, how about a quote: http://mercurial.selenic.com/wiki/RevisionNumber Pitfalls 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. Use the changeset ID instead. So I wouldn't really say that is just fine.
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
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).
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}, …). You don't have to specify the full SHA-1 hash either, as
long as it is still unambiguous – for example, you could just refer to
the 2.051 version mentioned above as »1374« to save typing.
David
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
I don't know. I haven't used Hg. However, I have a hard time seeing how you could have revision numbers like subversion does Mercurial uses hashes. For convenience it *additionally* provides consecutive numbers which are to be used in your own *local repo only*.
D Programming Language source (dmd, phobos, etc.) has moved to github
https://github.com/organizations/D-Programming-Language We're all learning how to use github, but by most accounts it seems to be the best available system for the diverse group of people who work on it.
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Dear Walter, I went to the github and try to download the source, I found that the latest version on github is the old version. for example: druntime - Downloads: dmd-2.042 Phobos - Downloads: phobos-2.046 DMD - Downloads: dmd-2.046 I think the actural latest version of D should be 2.051. Why github can not showing the 2.051 version(dmd, phobos, druntime, and so on.) ?
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
David Wang wrote: Dear Walter, I went to the github and try to download the source, I found that the latest version on github is the old version. for example: druntime - Downloads: dmd-2.042 Phobos - Downloads: phobos-2.046 DMD - Downloads: dmd-2.046 I think the actural latest version of D should be 2.051. Why github can not showing the 2.051 version(dmd, phobos, druntime, and so on.) ? I think it is because the tags were never done properly on svn, either.
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
On Sunday 23 January 2011 21:00:21 David Wang wrote: Dear Walter, I went to the github and try to download the source, I found that the latest version on github is the old version. for example: druntime - Downloads: dmd-2.042 Phobos - Downloads: phobos-2.046 DMD - Downloads: dmd-2.046 I think the actural latest version of D should be 2.051. Why github can not showing the 2.051 version(dmd, phobos, druntime, and so on.) ? If you grab the source with git, it's the latest version. I don't know how the downloads stuff works though - but as you say, it doesn't have the latest version. It will likely take some time to sort out all of the kinks of the transition though. From the looks of it, very few of the dmd/druntime/Phobos devs have experience with github. - Jonathan M Davis
