181–190 of 317 posts
The important take-away here isn't the relative merits of each DVCS, but that bzr is not used by anybody any more, and it is impeding the uptake of new contributors to Emacs.
>git won the mindshare war. I regret this - I would have preferred Mercurial, but it too is not looking real healthy these days I confess that my perception of Mercurial is the diametric opposite of the author's. Recently I believe I have seen a modest resurgence of interest in Hg and increased uptake. Am I just seeing this through some peculiar VCS-warped glasses? I believe that much of the popularity of git stems f…
Bazaar is a different story. Technically speaking, Bazaar isn't going away anytime soon. Canonical's development depends too much on it. The primary problem with Bazaar is that updates on Canonical's side are pretty much limited to dealing with issues that Canonical has, and there is little activity with respect to getting other bugs/issues fixed/addressed.
This is unfortunate, because Bazaar does do a few things better than either Git or Mercurial.
Earlier quoted context omitted.
Well, there's also the "social and signaling effects" of using something that's non-git, that Eric S. Raymond articulates well: "we cannot afford to make or adhere to choices that further cast the project as crusty, insular, and backward-looking."
Well, there's also the "social and signaling effects" of using something that's non-git The "not a field" of Computer Programming, to appropriate Alan Kay's quip, is so broken that "social and signaling effects" swamp actual facts and information to a degree that makes it look like Astrology. I've been watching this for decades now -- literally. Dynamic languages were for years after still tarred with being "slow" wh…
There are tons of people who use and know git. It's fast, it works pretty well. There's some value in the fact that it's widely known and used (network effects), probably enough that whatever takes its place will probably be not just a bit better, but a lot better, in some way. bzr does not strike me, offhand, as being a lot better. Is fossil?
So in this case, I think that the network effects are an important fact.
Earlier quoted context omitted.
Exactly. The git data model is intuitive and easy to grasp after a short amount of time. The porcelain is poorly designed, but part of that is due to the flexibility of primitives underneath, and the desire to support arbitrary workflows. Contrast with svn which attempts a very clean porcelain interface with a completely muddled data model underneath. The conflation of repositories, directories and branches in svn ma…
> the desire to support arbitrary workflows. Now I am laughing and laughing bitterly. git supports one workflow -- the massively decentralized one. To this day you can't have a simple workflow with git, the one that cvs/svn supported and practically all small project would benefit from, the one that bzr calls a bound branch. git , I believe , is the textbook case of what the opposite of a user friendly UI is. command…
What? Of course you can. I've worked on teams that did it. You are talking total rubbish.
Earlier quoted context omitted.
Apple still insists on building their kernel atop Mach, and it doesn't seem to stop their momentum. (Even though it's kind of a strange choice.)
From what I understand, the Mach kernel which is now used in XNU is not the Mach micro kernel (3.0 >) but based upon the pre-micro-kernel 2.5 version of Mach. I'm not sure where I read this originally but I just googled this source which seems to back it up: http://www.roughlydrafted.com/0506.mk3.html
https://developer.apple.com/library/mac/documentation/Darwin...
Oddly, both Bazaar, Git and Mercurial were created around March/April 2005. Why the sudden appearance of popular DVCSs around that time, and why did Bazaar fall behind the other two in popularity?
If you read the article included in the post it says that git, mercurial and bazaar all came together because Bitkeeper stopped being free. Now as for why bazaar didnt get used so much even when supported by canonical is a mystery to me.
Earlier quoted context omitted.
> Android (which while built of GNU/Linux pieces, is radically different from traditional GNU/Linux - enough to qualify as a different OS IMO, since the API is different). The "GNU/Linux" vs "Linux" discussion is a long one but I'm pretty sure there's (almost?) no GNU in Android.
There's GNU in android.
Android is very different from the GNU/Linux operating system
because it contains very little of GNU. Indeed, just about
the only component in common between Android and
GNU/Linux is Linux, the kernel.
Earlier quoted context omitted.
Does this make the issue a critique of RMS's management style, or of the FSF licensing that is unable to back out of a failed project?
If you look at the thread, it seems to be neither, just inertia. The licensing is fine, its GPL, no different from bzr.
Earlier quoted context omitted.
> It turns out however that Git is really easy to grasp. Please write something to explain it. I must be pretty dumb, because I don't get it, even after reading about ten explanatory texts.
Since you have already read ten things about it and don't understand it, it would help if you told us what you do not understand so that we do not waste our time rehashing things that you have already not understood.
Branching/merging/committing is pretty straightforward. The problem is that some commands seem to be very convoluted. For example, why does reset do four different things depending on whether it's soft or hard or plain? I keep having to Google to find how I can revert my latest commit.
Another thing I have trouble with is obscure failures. Obviously this isn't something I can just learn, but there are times when git fails for a reason I don't understand...
Earlier quoted context omitted.
> it doesn't paint Stallman very well as the head of a project Is this news to you? Cf. e.g. http://www.jwz.org/doc/lemacs.html
I'm not sure that conversation is a good example of what you are trying to describe. Let's see if someone did the following things to the python project: 1#: Hire away the package maintainer. Then rather than continue and finish any current work, effectively remove that person from the community project. 2#: Redesign underlying structure of the project (like say, PyPy), but don't discuss any changes with the communit…
I also read the argument about the redesign of the event system and was pretty flabbergasted. The argument seems to reduce to "lucid emacs decided to design a proper event datatype because having an event be entirely represented by a simple integer keycode both lost information and made it impossible to represent certain keystrokes" versus "but ints are simple and backward compatible!"