Re: DVM - D Version Manager
On 2011-01-25 23:30, Jérôme M. Berger wrote: Jacob Carlborg wrote: On 2011-01-25 20:33, Jérôme M. Berger wrote: Jacob Carlborg wrote: Platforms: currently only Posix Nitpick: it is more restricted than that. Platform is currently only posix *with bash shell*. A lot of people use other shells, including non-Bourne shells (most frequent are zsh, ksh and tcsh). Jerome Yeah, I guess you're right, didn't think there were a lot people who used other shells. Since I almost know nothing about shell scripting and even less about non-bourne shells, will it be possible to port to other shells? How much do they differ? Well, for other Bourne shells (like zsh or ksh), it will probably mostly be a question of putting the initialization code in the right file (i.e. .zshrc or .kshrc). Other than that, unless you are doing something pretty fancy, the same code should work. For C-shells (like tcsh) the syntax is pretty different, so it will probably require more changes. However, it has been a while since I last used tcsh, so I cannot tell you how much work it would be. Jerome Ok. -- /Jacob Carlborg
Re: DVM - D Version Manager
On 2011-01-25 23:59, Jesse Phillips wrote: Jacob Carlborg Wrote: Yeah, I guess you're right, didn't think there were a lot people who used other shells. Since I almost know nothing about shell scripting and even less about non-bourne shells, will it be possible to port to other shells? How much do they differ? -- /Jacob Carlborg To add to Lutger's message. I believe it is sh that is required by all Posix systems, or at least an equivalent. Similarly I think vi is also a requirement. In all likelyhood you probably used a Bash specific feature, but usually everyone has bash even if they use zsh... Though Ubuntu/Debian has started pointing /bin/sh to dash which is complaint with posix... Ok. I'll see I can use only sh. -- /Jacob Carlborg
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: DVM - D Version Manager
On Wed, 26 Jan 2011 03:36:24 -0500, Jacob Carlborg d...@me.com wrote: On 2011-01-25 23:59, Jesse Phillips wrote: Jacob Carlborg Wrote: Yeah, I guess you're right, didn't think there were a lot people who used other shells. Since I almost know nothing about shell scripting and even less about non-bourne shells, will it be possible to port to other shells? How much do they differ? -- /Jacob Carlborg To add to Lutger's message. I believe it is sh that is required by all Posix systems, or at least an equivalent. Similarly I think vi is also a requirement. In all likelyhood you probably used a Bash specific feature, but usually everyone has bash even if they use zsh... Though Ubuntu/Debian has started pointing /bin/sh to dash which is complaint with posix... Ok. I'll see I can use only sh. FWIW, /bin/sh is usually a symlink to bash, and it makes bash behave like the original Bourne Shell. I typically find /bin/sh features to be enough for implementing most scripts. A good reference (if you don't have it) is Unix in a nutshell, probably my most used textbook. -Steve
Re: DVM - D Version Manager
On Wed, 2011-01-26 at 08:58 -0500, Steven Schveighoffer wrote: [ . . . ] FWIW, /bin/sh is usually a symlink to bash, and it makes bash behave like the original Bourne Shell. For some definition of usually. On Debian and Ubuntu /bin/sh is a symbolic link to dash not bash. I typically find /bin/sh features to be enough for implementing most scripts. And the only guaranteed portable script -- assuming Windows without Cygwin or MSYS is excluded ! [ . . . ] -- 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
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: DVM - D Version Manager
Steven Schveighoffer Wrote: On my ubuntu system too -- to my surprise ;) It is a new thing they did, about a release or two ago. The reason was because /bin/sh pointed to bash and _did not_ adhere to the sh standard.
Re: DVM - D Version Manager
On 2011-01-26, Jesse Phillips jessekphillip...@gmail.com wrote: Steven Schveighoffer Wrote: On my ubuntu system too -- to my surprise ;) It is a new thing they did, about a release or two ago. The reason was because /bin/sh pointed to bash and _did not_ adhere to the sh standard. It was a system speed enhancement. Much of the bootup speed gain was due to switching to dash. bash is slow. bash adhere's to sh standards is just fine except that it won't flag extensions, so you can still end up with bashisms in your shell script. I've never had any issues w/bash. I write shell scripts that run in bash2, bash3, bash4, ash, dash, ksh88, ksh93, mksh, SunOS sh, Tru64 sh, AIX sh, HP-UX sh.
Re: DVM - D Version Manager
Jacob Carlborg wrote: On 2011-01-25 23:59, Jesse Phillips wrote: Jacob Carlborg Wrote: Yeah, I guess you're right, didn't think there were a lot people who used other shells. Since I almost know nothing about shell scripting and even less about non-bourne shells, will it be possible to port to other shells? How much do they differ? -- /Jacob Carlborg To add to Lutger's message. I believe it is sh that is required by all Posix systems, or at least an equivalent. Similarly I think vi is also a requirement. In all likelyhood you probably used a Bash specific feature, but usually everyone has bash even if they use zsh... Though Ubuntu/Debian has started pointing /bin/sh to dash which is complaint with posix... Ok. I'll see I can use only sh. You cannot. You need to modify the environment for the current shell, which is the shell that the user is currently using (no matter what else may or may not be installed on the system). This has two consequences: - You need to have some code that is run when the shell starts (i.e. from .bashrc, .zshrc or .kshrc). That code will define the proper aliases and/or functions (at the time being, this is mostly the dvm function in dvm.sh (*)). This can be accomplished by having a different version of this file for each shell; - You need to generate the contents of $dvm_result_path in a format that the shell will understand. The easiest way to do that is probably to define a few extra functions in dvm.sh to enable setting environment variables in a portable way and handle additional requirements (like builtin hash -r which is definitely a bash-ism). Then generate the $dvm_result_path using these functions instead of the normal shell syntax. Jerome (*) BTW, I hope you do not add the full contents of dvm.sh nor a source dvm.sh in .bashrc the way it is now. Otherwise, a misconfiguration may prevent the user from starting a shell! -- 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
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: DVM - D Version Manager
On Wed, 26 Jan 2011 15:24:56 -0500, Jacob Carlborg d...@me.com wrote: On 2011-01-26 14:58, Steven Schveighoffer wrote: On Wed, 26 Jan 2011 03:36:24 -0500, Jacob Carlborg d...@me.com wrote: On 2011-01-25 23:59, Jesse Phillips wrote: Jacob Carlborg Wrote: Yeah, I guess you're right, didn't think there were a lot people who used other shells. Since I almost know nothing about shell scripting and even less about non-bourne shells, will it be possible to port to other shells? How much do they differ? -- /Jacob Carlborg To add to Lutger's message. I believe it is sh that is required by all Posix systems, or at least an equivalent. Similarly I think vi is also a requirement. In all likelyhood you probably used a Bash specific feature, but usually everyone has bash even if they use zsh... Though Ubuntu/Debian has started pointing /bin/sh to dash which is complaint with posix... Ok. I'll see I can use only sh. FWIW, /bin/sh is usually a symlink to bash, and it makes bash behave like the original Bourne Shell. /bin/sh is not a symlink on Mac OS X. I guess I just can try to use sh instead of bash. Yes, it should limit you to /bin/sh supported commands I typically find /bin/sh features to be enough for implementing most scripts. I have no idea. I need to be able use the following commands/functions: export, source, builtin hash, rm, echo, exit, exec export = supported, but has a more limited syntax than bash source = supported via . builtin hash = supported rm = command (shell independent) exit = supported exec = supported -Steve
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: DVM - D Version Manager
Jacob Carlborg d...@me.com wrote in message news:ihq02n$28ki$1...@digitalmars.com... On 2011-01-26 14:58, Steven Schveighoffer wrote: On Wed, 26 Jan 2011 03:36:24 -0500, Jacob Carlborg d...@me.com wrote: I typically find /bin/sh features to be enough for implementing most scripts. I have no idea. I need to be able use the following commands/functions: export, source, builtin hash, rm, echo, exit, exec Can't all (or most) of that be done in straight D?
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: DVM - D Version Manager
On 2011-01-26 21:53, Nick Sabalausky wrote: Jacob Carlborgd...@me.com wrote in message news:ihq02n$28ki$1...@digitalmars.com... On 2011-01-26 14:58, Steven Schveighoffer wrote: On Wed, 26 Jan 2011 03:36:24 -0500, Jacob Carlborgd...@me.com wrote: I typically find /bin/sh features to be enough for implementing most scripts. I have no idea. I need to be able use the following commands/functions: export, source, builtin hash, rm, echo, exit, exec Can't all (or most) of that be done in straight D? It all comes done to one thing, the source function. If you launch an application in a shell that application can't set environment variables that will be available to the shell when the application exits. So instead I have most of the application written in D with a bash function that wraps the application. It works like this: 1. The function calls the D application 2. The D application performs all it needs to and writes a shell script to a file 3. The bash function calls source with this file as a parameter -- /Jacob Carlborg
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: DVM - D Version Manager
On 2011-01-26 15:24:56 -0500, Jacob Carlborg d...@me.com said: /bin/sh is not a symlink on Mac OS X. I guess I just can try to use sh instead of bash. But should it output this? $ /bin/sh --version GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin10.0) Copyright (C) 2007 Free Software Foundation, Inc. $ This is on Mac OS X 10.6.6. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
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.
