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

161–170 of 171 posts

Re: Apache considered harmful

#161

Post by wladimir »

tptacek wrote: post #144
wladimir wrote: post #75

Earlier quoted context omitted.

You of all people should know that GIT history consists of a write-only log which is maintained using cryptographic hashes. If you edit one commit (even the metadata) you have to rewrite history, and all the hashes for commits after it change. People will notice, and most importantly, everyone will still have the old commit chain locally. This means that even the server cannot arbitrarily edit history. With SVN, afai…

"Me of all people"? People sure are zealous about their version control systems. For the record, I use git. But I don't really give a shit about it. For most of my career, I used CVS. Git is neat, and I like it, but I'm not planning on studying its internals any time soon.

Right. But it is useful to know, not so much because of the VCS aspect, but because of the security aspect. Hg/Mercurial BTW works in the same way.

Re: Apache considered harmful

#162

Post by buff-a »

cube13 wrote: post #131
buff-a wrote: post #111

Earlier quoted context omitted.

What you describe is the original use case for git: pull-based community development. So I can only conclude that you don't see a problem because you've never actually done it.

Which is the exact basic use case for almost all modern source control systems. Git doesn't do anything new or unique for that use case.

All server based vcs are push based. Certainly they can be used pull-based, where others diff code, send the patch, and a committer then integrates and commits. Git, on the other hand does two things differently. 1) it makes it vastly easier to create, submit, and integrate patches (because it was designed for it) and 2) it makes it vastly easier for the people making the patches, who don't have commit privs, to maintain their changes in their own repo, while still syncing with the master.

svn does not offer these features, which means that when you dont have commit privs, its a PITA to track and maintain your own version. I'll say that again: it makes it massively frustrating to maintain your own version. The result is that people dont, and the number of potential hackers is vastly reduced.

git, like svn, allows a small community, such as ASF, to manage and control a project - addressing legal and operational concerns. committers can push just as easily as with svn. but in addition, each committer can (if they so choose) also maintain relationships with a much greater community, each member of which can hack away on their own with a fully synced, fully versioned repo of their own. hackers get their own repo. committers have a really robust system for integrating patches.

If ASF wishes to do no more than have a small number of committers working on a project then indeed, svn suffices. its "good enough". the point of mikeal's post is that this is missing out hugely on the vast army of hackers.

I said in an earlier post that I had no skin in the game. that's true. now. i used to track tomcat. but it was such a pain in the arse to handle merging my code with the official code that I gave up. it just wasnt worth it. git would have solved every problem I had. perhaps by now I would be a committer on the tomcat project. who knows? svn made that a certain "no".

an organization like ASF needs a finite number of committers. git allows keeping that group small, yet engaging a much greater community.

but as mikeal says, its not about svn vs git. its about the mindset that sees no need for git because it sees no need for more than just committers.

Re: Apache considered harmful

#163

Post by yummyfajitas »

spiffytech wrote: post #160
yummyfajitas wrote: post #108

Earlier quoted context omitted.

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.

Almost, but not quite. As far as I know, svn doesn't support rebase -i.

Also, part of the point of the workflow is to make sure all commits to the official repo are clean code. Using a feature branch means that the official repo contains commits like "Halfassed implementation of foo, joe take a look at it".

Re: Apache considered harmful

#164

Post by danssig »

Someone wrote: post #155
danssig wrote: post #91

Earlier quoted context omitted.

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 comp…

>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

No, it is. You can't "falsify a complete repository". We will all have checked out from that repo and as soon as someone replaces it with a fake none of the hashes will match up.

>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.

Which happens in the system automatically. Have you actually worked with Git? Go change history on something you've pushed and other people have pulled.

>number of people keeping a copy who will not blindly copy changes from the 'main' repository.

It's not about "blindly copy changes". If you pull from a repo where someone has tried to rewrite history you'll see duplicate entries all over your log. If you have a graphical tool you'll see right where they started their modification.

Re: Apache considered harmful

#165

Post by EdiX »

nirvdrum wrote: post #146
EdiX wrote: post #142

Earlier quoted context omitted.

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

You certainly implied a branch-free workflow. Otherwise why would you have a dirty local workspace and multiple checkouts? And why would committing break a build? I'm unaware of any CI server configured to build every branch in the SVN tree.

Do you make a branch every time you change something? Do you make a branch for every developer's local copy?

The thing is, when you solve the problem of dirty local workspaces by making them actual branches svn becomes just as complex as git, probably even more so given that all the branches exist for all the users. And you still don't have has good interface for cherry-picking, you still need multiple local copies, it still isn't as fast and you still don't have all the other benefits associated with a DVCS.

Re: Apache considered harmful

#166

Post by fanf2 »

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.

I have here a svn checkout of the FreeBSD HEAD branch, using 1550 MB disk in 199443 files.

I also have a git checkout of the same thing, which includes the history of the HEAD but not the other branches. It is 1234 MB in 54823 files.

Re: Apache considered harmful

#167

Post by aristedes »

msbarnett wrote: post #149
aristedes wrote: post #85

Where to start with this blog post? It appears that the author has seen a couple of private emails and thinks he knows all about the internal workings of the Apache Foundation. He is wrong on so many counts. His entire dislike of the Apache Foundation appears to be predicated on the fact that the organisation did not force every project to move to this blogger's favourite version control tool. Making a change as larg…

> 2. Legal change. Right now there is a simple process for signing off intellectual property for contributions which were merged from external contributors (who have not signed a release). That changes with git and becomes more complex. There are solutions, but they require careful planning. I'm curious as to how exactly you feel git impacts on Legal processes versus the use of svn. I'd expect that the choice of tool…

With an svn workflow the committer sends each patch in a single authenticated request directly to the Apache svn server. With every commit they are saying "this code is appropriately licensed, even though the code may have come from other committers. The history of that code is completely obscured."

With a git workflow, the push (which is authenticated against a committer who has signed the appropriate license agreement) could contain multiple commits from other sources. This is particularly the case if it includes code from a pull request. The Apache git tree will then have commits with publically visible attribution to people who are not Apache committers and may not have signed the appropriate license agreements.

I am not saying this is a deal breaker, but it does require some thought. We don't want some contributor to come back three years later and say "that contribution from me: it was only released under the GPL". We need clear guidelines around that original pull request and how copyright/patent signoff happens. Right now, third party contributions go through a Jira patch process which includes a copyright/assignment tick box.

Re: Apache considered harmful

#168

Post by aristedes »

soc88 wrote: post #96
aristedes wrote: post #85

Where to start with this blog post? It appears that the author has seen a couple of private emails and thinks he knows all about the internal workings of the Apache Foundation. He is wrong on so many counts. His entire dislike of the Apache Foundation appears to be predicated on the fact that the organisation did not force every project to move to this blogger's favourite version control tool. Making a change as larg…

The ASF is missing the boat here. It is like ... the 21st century? And core people of the Apache are not only thinking “SVN should be enough for everyone” but also make it exceptionally hard for projects to use the rigth tool for their job. My bet is still on Git being shot down due to some random made-up “quality concerns” in the end. ASF went from a helpful free software organization to a software graveyard: Ant, M…

Are you just trolling or trying to make some point? What part of "Apache is currently evaluating git" makes you feel that git is being shot down?

Git is just a tool. In five years there will be another tool that everyone cannot live without. And people like you will be telling Apache that they are dinosaurs because they have not moved to that. Right now some very dedicated and skilled people are donating their free time to running the Apache organisation and evaluating the feasibility of making changes. And you accuse them of lying about quality concerns (which no one has even raised). Meanwhile, your assistance to the advancement of open source is what exactly?

Re: Apache considered harmful

#169

Post by msbarnett »

aristedes wrote: post #167
msbarnett wrote: post #149

Earlier quoted context omitted.

> 2. Legal change. Right now there is a simple process for signing off intellectual property for contributions which were merged from external contributors (who have not signed a release). That changes with git and becomes more complex. There are solutions, but they require careful planning. I'm curious as to how exactly you feel git impacts on Legal processes versus the use of svn. I'd expect that the choice of tool…

With an svn workflow the committer sends each patch in a single authenticated request directly to the Apache svn server. With every commit they are saying "this code is appropriately licensed, even though the code may have come from other committers. The history of that code is completely obscured." With a git workflow, the push (which is authenticated against a committer who has signed the appropriate license agreem…

Doesn't simply requiring that all pull requests be squashed down to a single clean commit from a developer known to have signed the license agreements give you back the exact scenario you have under SVN?

Anecdotally, a lot of projects I've been involved with have required that pull requests be squashed to avoid polluting the "main" repo with irrelevant/undesired third-party history.

Re: Apache considered harmful

#170

Post by nirvdrum »

EdiX wrote: post #165
nirvdrum wrote: post #146

Earlier quoted context omitted.

You certainly implied a branch-free workflow. Otherwise why would you have a dirty local workspace and multiple checkouts? And why would committing break a build? I'm unaware of any CI server configured to build every branch in the SVN tree.

Do you make a branch every time you change something? Do you make a branch for every developer's local copy? The thing is, when you solve the problem of dirty local workspaces by making them actual branches svn becomes just as complex as git, probably even more so given that all the branches exist for all the users. And you still don't have has good interface for cherry-picking, you still need multiple local copies,…

You don't need multiple local copies. That's why "svn switch" exists. That's all I was addressing. Some of the things you knock SVN for are either non-issues or issues with git as well. E.g., "branches exist for all users" is a non-issue. Otherwise it's also a problem when I push a git branch (which is a wise thing to do).

Cherry-picking and speed are legitimate benefits of git.

Post reply on HN