Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bzr is dying; Emacs needs to move

lists.gnu.org

Post reply on HN
Print view View original

251–260 of 317 posts

Re: Bzr is dying; Emacs needs to move

#251

Post by pedrocr »

lmm wrote: post #203
pedrocr wrote: post #160

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.

I don't normally say "GNU/Linux", but I felt this was a case where the distinction is particularly important, because Android does run the Linux kernel, but is (IMO) a different OS from GNU/Linux.

Right. The reason I made my comment was because you said "which while built of GNU/Linux pieces" referring to Android, which doesn't make sense.

Re: Bzr is dying; Emacs needs to move

#252

Post by jordigh »

petertodd wrote: post #219
binarycrusader wrote: post #152

Earlier quoted context omitted.

Yep, I don't understand the author's assertions about Mercurial either. Mercurial remains a better choice for a few use cases where git simply falls flat. Among game developers, in particular, because of their need to have revision control for large assets, Mercurial seems to be more popular than git due to the large files extension. And realistically, perforce or other solutions appear to be even more popular among…

Git now has the git-annex extension for large files; I use it myself for all my data. http://git-annex.branchable.com/

It's not the same thing. That only stores the latest revision. You can't easily go back in history and check out earlier revisions of the large files. You can in hg.

Re: Bzr is dying; Emacs needs to move

#253

Post by Sssnake »

lmm wrote: post #81
xradionut wrote: post #42

Earlier quoted context omitted.

I hate when people say "git won the war", it sounds like an excuse to close minds and stop progress. What if "Microsoft won the war"? Or vim? Or IBM? Or Java? Or Taco Bell?

Microsoft did win the war; very little progress has been made by its competitors from the time; what's had success has been new OSes - OSX, iOS and 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). Vim did win the war; there's still nothing better. IBM did win the war, and then shot themselves in th…

>Vim did win the war; there's still nothing better.

Haha, good one. Many of vim's predecessors are better even, nvi is far nicer to use than vim is for example.

Re: Bzr is dying; Emacs needs to move

#254

Post by codereflection »

chebucto wrote: post #162
hyperpape wrote: post #83

I went back and looked at the older discussion, and it doesn't paint Stallman very well as the head of a project. He pins the question of whether to keep using bzr not on whether it is good or whether the Emacs developers want it, but on whether it's being "maintained". But then he seems to define maintenance as having fixed a specific bug that's been around for over a year, blocking a point release. He admits that h…

As he said, 'more than Emacs is at stake here.'.[1] I presume this refers to Bazaar's status as part of the GNU project, and that RMS did not want to write off part of GNU without being certain he needed to. Regardless, he has since OKd the switch from bzr: I don't insist that Emacs should stay with bzr. I chose to support bzr because it was still a contender at the time. [2] [1] https://lists.gnu.org/archive/html/em…

I think Stallman is being reasonable here.

Re: Bzr is dying; Emacs needs to move

#255

Post by Crito »

lmm wrote: post #234
Crito wrote: post #221

Earlier quoted context omitted.

Set up a repo on a server somewhere and declare it to be the "central repo". You and the other developer pull/push from that repo only. In other words, ignore some of git's capabilities and treating git like SVN. Just because you can pull from your teammates, does not mean that you have to. I've been on a team that transitioned from SVN to Perforce, the again to Git, keeping the same workflow all the way through. It…

> Set up a repo on a server somewhere and declare it to be the "central repo" That's the situation I described. We still have the problems I mentioned: sometimes we commit without pushing (particularly because we sometimes didn't set a branch to be remote-tracking and didn't realize this), and sometimes our branches are behind our copy-of-the-remote-branch because we pulled different branches (which leads to bogus me…

Committing without pushing is not a problem (unless you intended to push but forgot to?) It is not a concept that necessarily exists in traditional centralized version control systems, but the fundamental problem still exists. In SVN "forgetting to push" is just called "forgetting to commit".

If your team member forgot to push and you put out new changes, that is a problem for him to resolve. If you forgot to push, and your team member put out new changes, that is a problem for you to resolve. Workflow wise, this all works the same as it does with any other centralized workflow.

If you forget to check for updates... well that is something that happens in other centralized schemes as well. You figure it out when you go to push and it fails, you correct it, then you are good to go.

Re: Bzr is dying; Emacs needs to move

#256

Post by dragonwriter »

vezzy-fnord wrote: post #136
IgorPartola wrote: post #133

Earlier quoted context omitted.

That's a simplistic view. First, the GNU project is very much alive: the GNU tools are used in a huge number of operating systems and are installed on a staggering number of devices. I would bet that the system you are writing this comment from is running thanks to the GNU software. Second, it is debatable whether sticking to Hurd was a good or a bad idea technically . Imagine if Stallman and co. managed to convince…

Wait. You misunderstood me. I didn't say the entire GNU Project is dead. Hell no. When I said "project", I was referring specifically to GNU Hurd . Also my statement was going by the words of the Hurd's former project leader Thomas Bushnell: "RMS was a very strong believer -- wrongly, I think -- in a very greedy-algorithm approach to code reuse issues. My first choice was to take the BSD 4.4-Lite release and make a k…

Note, in regard to Bushnell's quote, that "1991 or so" and "way before Linux" are contradictory. (Or, at least, require an strained definition of "way before"; Linux was first released in 1991.)

Re: Bzr is dying; Emacs needs to move

#257

Post by taspeotis »

voltagex_ wrote: post #242
binarycrusader wrote: post #227

Earlier quoted context omitted.

Most game devs -- I'd say even most devs in grown-up, professional shops -- use p4. Hence why I said "realistically, perforce or other solutions appear to be even more popular among that particular developer segment." My comment you quoted was comparing the popularity of Mercurial to Git, not p4. Also, I'd disagree with your assertion regarding "most devs in grown-up, professional shops". Microsoft's SourceSafe has a…

Are that many people really using SourceSafe still? TFS is now Microsoft's preferred solution, although I don't know what they use internally.

Disclaimer: I'm not a Microsoftie, just collecting some links and adding my own opinion.

Microsoft use TFS heavily [1].

Right now I imagine most MS projects are TFS but it doesn't appear to be mandated. Maybe for the big, internal-only stuff. ASP.NET is hosted on CodePlex as a Git repo [2] and MEF is Hg [3].

They've just added Git support to TFS and that probably means a lot of MS projects will migrate to Git over time.

[1] http://blogs.msdn.com/b/visualstudioalm/archive/2013/08/20/t...

[2] http://aspnetwebstack.codeplex.com/

[3] https://mef.codeplex.com/SourceControl/latest#.hgignore

Re: Bzr is dying; Emacs needs to move

#258

Post by lmm »

Crito wrote: post #255
lmm wrote: post #234

Earlier quoted context omitted.

> Set up a repo on a server somewhere and declare it to be the "central repo" That's the situation I described. We still have the problems I mentioned: sometimes we commit without pushing (particularly because we sometimes didn't set a branch to be remote-tracking and didn't realize this), and sometimes our branches are behind our copy-of-the-remote-branch because we pulled different branches (which leads to bogus me…

Committing without pushing is not a problem (unless you intended to push but forgot to?) It is not a concept that necessarily exists in traditional centralized version control systems, but the fundamental problem still exists. In SVN "forgetting to push" is just called "forgetting to commit" . If your team member forgot to push and you put out new changes, that is a problem for him to resolve. If you forgot to push,…

> Committing without pushing is not a problem (unless you intended to push but forgot to?) It is not a concept that necessarily exists in traditional centralized version control systems, but the fundamental problem still exists. In SVN "forgetting to push" is just called "forgetting to commit".

Sure, but you hit the problem twice as often in git, because you have to do twice as many things.

> If you forget to check for updates... well that is something that happens in other centralized schemes as well. You figure it out when you go to push and it fails, you correct it, then you are good to go.

In SVN that doesn't show up as a merge in the history.

Re: Bzr is dying; Emacs needs to move

#259

Post by [deleted] »

voltagex_ wrote: post #242
binarycrusader wrote: post #227

Earlier quoted context omitted.

Most game devs -- I'd say even most devs in grown-up, professional shops -- use p4. Hence why I said "realistically, perforce or other solutions appear to be even more popular among that particular developer segment." My comment you quoted was comparing the popularity of Mercurial to Git, not p4. Also, I'd disagree with your assertion regarding "most devs in grown-up, professional shops". Microsoft's SourceSafe has a…

Are that many people really using SourceSafe still? TFS is now Microsoft's preferred solution, although I don't know what they use internally.

[deleted]

Re: Bzr is dying; Emacs needs to move

#260

Post by lmm »

eropple wrote: post #247
lmm wrote: post #215

Earlier quoted context omitted.

I'm a happy git user, but tell me how this is supposed to work: there's me and one other guy working on a project. There are three logical branches: trunk, his branch, and my branch. In SVN there would be five source trees: those three on the server, his working copy and my working copy. But in git we end up with fifteen: the three on the server, my branch on my machine, his branch on my machine, master on my machine…

Is there a reason you aren't using disposable feature branches? I don't track my other developers' feature branches locally unless I need to view them.

You're right, thinking about it - most of the time I wouldn't have a copy of my coworker's branch (though we do sometimes pull changes from each other's feature branches - indeed that's supposed to be the big advantage of git, no?)
Post reply on HN