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

Apache considered harmful

mikealrogers.com

Post reply on HN
Print view View original

151–160 of 171 posts

Re: Apache considered harmful

#151

Post by rimantas »

nirvdrum wrote: post #121
rimantas wrote: post #73

Earlier quoted context omitted.

There is no issue with the size of the local copy. Most of the times the entire git repo is smaller than single SVN checkout.

I don't think I've ever seen a situation where that's true. And I've converted a lot of repositories (I maintain the svn2git project). SVN has its metafiles, but git has the full history locally. In all but the most trivially-sized projects, the git clone is bound to be larger. For larger projects it can be several orders of magnitude larger.

Git also has much more efficient storage mechanism.

Re: Apache considered harmful

#152

Post by rgardler »

v21 wrote: post #99
ww520 wrote: post #13

I'm curious how does it harm anything? Did it kill any puppies? Maybe it's inefficient but harmful? Also remember GitHub is a for profit company. Its allowance for Open Source hosting is a marketing tactic. Anytime they feel the marketing value is not there, they will shut it down. Not that I'm against GitHub. It's a great company for itself. But comparing the Apache to GitHub is like comparing apple and orange.

It harms the opportunity cost of the projects that reside within it. That's a real harm. And I think the point is that while GitHub is there, use it. If it closes off, or goes bust, migrate. You can extract all your data - keep a backup elsewhere. At worst, you can move to Gitorious. I mean, currently they use JIRA for bug tracking - that's not an open project either, that's run by Atlassian.

Projects choose to go to the ASF. Who are you, or anyone else, to tell them it is not the right choice? Billions of dollars are made and saved every year thanks to ASF software (hell it's even in space)- there is a reason for that.

Can the ASF environment be improved for its projects? Of course it can - see my other comments where I address this point.

Re: Apache considered harmful

#153

Post by nirvdrum »

rimantas wrote: post #151
nirvdrum wrote: post #121

Earlier quoted context omitted.

I don't think I've ever seen a situation where that's true. And I've converted a lot of repositories (I maintain the svn2git project). SVN has its metafiles, but git has the full history locally. In all but the most trivially-sized projects, the git clone is bound to be larger. For larger projects it can be several orders of magnitude larger.

Git also has much more efficient storage mechanism.

I'm aware of that and didn't imply otherwise. But the storage mechanism is for the history, not for the materialized files in the working directory. That's going to be the same for either git or SVN, since they're checked out. So you're talking about comparing git's history DB to SVN's metadata files. The metadata files are effectively constant cost whereas the git history grows with each checkin. They get quite large.

Re: Apache considered harmful

#154

Post by nirvdrum »

hesselink wrote: post #147
nirvdrum wrote: post #120

Earlier quoted context omitted.

It's not terribly great when you have large files in the system. You end up with a huge repository on disk as those files change. But more importantly, you can't do a partial checkout of a particular path. I think I read that that'll be coming to git, which would be fantastic.

Actually, you can, with sparse checkouts. They've been in since git 1.7, if I remember correctly. It's not very user friendly yet, and you do retain the entire path from the repository root. See for example here: http://vmiklos.hu/blog/sparse-checkout-example-in-git-1-7

Great. I'll have to check that out. Thanks for the link.

Re: Apache considered harmful

#155

Post by Someone »

danssig wrote: post #91
DannoHung wrote: post #34

Earlier quoted context omitted.

I'm not super familiar with subversion's internals, but couldn't a malicious user edit a subversion repo history?

That's the best part: if you have access to the source SVN repo you can change history and there will be no evidence that you did so. History in Git, on the other hand, cannot be modified without it showing up. The reason is that in Git every commit gets its own unique hash so you can't change a commit without creating a new hash. To have this in SVN you have to buy 3rd party tools.

I do not think it is as black and white as you describe it. The way I see it: if somebody falsifies a complete repository, the only way to detect that it was changed is by comparing its content or a hash thereof with that of a (supposed) copy that is more trusted.

That is true for any digital archive, including those made by any SCM system. The only thing where git differs from svn in that respect are a) that it computes such hashes for you, and (typically/AFAIK) shows those hashes in its UI, and b) that it is typical for people to store those hashes on other systems. The net effect of that may be large or small, depending on the number of people keeping a copy who will not blindly copy changes from the 'main' repository.

Re: Apache considered harmful

#156

Post by mef »

umarmung wrote: post #45
mef wrote: post #22

Earlier quoted context omitted.

what about Subversion goes "straight to the core" of the ASF that is not also true about git?

Subversion is a centralised or push model. Git is a distributed or pull model. This is at the heart of the processes one may use, certainly within a project but possibly at cross-project or organisational model.

what processes does the ASF use cross-project or cross-organizational which could not be replicated in a git environment?

Re: Apache considered harmful

#157

Post by kahawe »

buff-a wrote: post #115
kahawe wrote: post #83

Earlier quoted context omitted.

Spot on, excellent points and I could not help but wonder about the article... most people would consider "apache" to be synonymous for the httpd and not the ASF, so the headline is clearly fishing. Then, OP argues ASF's processes are broken and a github project with one maintainer is so much easier... you really have to consider the scale of the average sourceforge (back in the day) project vs. apache even back then…

So after telling us that your current environment is working with people who have a hard time with svn/cvs, forgive me if I find your opinion on git's ability to handle the requirements of large-scale, community driven development of the code that pretty much runs the internet to be utterly irrelevant. No. The kind of people who cannot handle cvs/svn update concepts are not the target demographic for a solution used…

Did you even read what I wrote? Your comment is irrelevant because you obviously did not understand my point: that git is not a "simply better" substitute for svn as a lot of people seem to think. There are situations where svn is the right tool for the job, my example is one of those situations in my opinion. So yes, definitely are they NOT the target audience for git - exactly my point.

Re: Apache considered harmful

#158

Post by kahawe »

EdiX wrote: post #142
nirvdrum wrote: post #136

Earlier quoted context omitted.

SVN has branches, too. The problem it had was with merge-tracking and that's about when everyone hopped over to git (myself included). But that hasn't been an issue for a couple years now. By all means, stick with git if you prefer it, but release some of the older criticisms as they've been addressed by the SVN team.

> SVN has branches, too. I don't think I have said it doesn't

> I don't think I have said it doesn't

But those branches would be a solution to the "I cannot commit this yet" problem. And at least on the repository side it is a cheap FSFS copy.

However, I don't want to make them branch because it would pose the same issues unfortunately...

Re: Apache considered harmful

#159

Post by lucisferre »

jaaron wrote: post #65
mikealrogers wrote: post #52

Earlier quoted context omitted.

This is perhaps the most depressing response I've received to my article. As I said in my article this is far less about git and more about the chasm that has grown between Apache and the rest of the community. Your first two points boil down to "nobody makes you join Apache, if you don't like our policies then you can get out". How does this help Apache or its projects? Apache could still be valuable to the communit…

"How does this help Apache or its projects?" The Apache Foundation is what you make of it. It will not change just because you post to your blog, but it will change if you engage the committer and membership population, build a consensus around your ideas and volunteer to do the actual work to make the changes happen. No one will force you to do such work and if you don't want to do it, then you're not obligated to d…

I believe he did engage the committer and membership population. You're response, disagreement or not, is proof of that. Disparaging the way he did it with statements like "just because you post to your blog" is completely unfair.

Re: Apache considered harmful

#160

Post by spiffytech »

yummyfajitas wrote: post #108
kahawe wrote: post #98

Earlier quoted context omitted.

> I am sorry to tell you, but you are plain wrong! Git is better. Please, do elaborate! In detail, why is git better than subversion if all I need is a central repository for a few people working at a company on one site, sitting in the same room with permanent network access. No distributed or remote or on-the-go development, no forks. > SVN embraces a workflow that is inferior. It is different but what exactly make…

In detail, why is git better than subversion if all I need is a central repository for a few people working at a company on one site, sitting in the same room with permanent network access. I was in exactly this situation at my last job (minus the same room, I was stuck in a separate office). In spite of the main source repo being SVN, we all used git-svn as our client. The main benefit is that git makes it easier to…

This workflow sounds like it could be replaced by creating a feature branch, developing the feature there, then merging the branch back into trunk when the feature is complete. This can be implemented in ordinary SVN, without git or git-svn.
Post reply on HN