Hacker News Reader

Comment by jaaron | Hacker News Reader

Ok, there's a lot to cover here.

First off, the Apache Software Foundation isn't trying to absorb anyone or anything. Projects and people come to the ASF. It's a specific policy of the Foundation to NOT solicit projects. If someone says they're representing Apache and soliciting projects, they're wrong.

Secondly, Apache is very opinionated about how projects should be run. This comes from years of experience as not only a successful project, but as a successful non-profit organization overseeing dozens of projects. If a community doesn't like the ASF's style or rules (such as no dictators, benevolent or otherwise), they don't need to be there. No one wants to keep projects hostage. Part of the point of the Incubator is to get this figured out earlier than later.

Thirdly, about git and subversion. First off, there's increasing support for git at Apache (see http://git.apache.org/) but there are some serious drawbacks for use of git. Consider this: subversion was practically made for Apache in the way Linus made git for Linux. With that in mind, subversion isn't going anywhere at the ASF. Some of the rational is just plain stubbornness, but some of it goes straight to the core values of the Foundation.

Apache has become, for better or worse, the place where lots of projects go when they grow up. Growing up is hard to do. It's not fun. You have to do things like get a job, pay taxes, etc. When a project grows up, people start caring about who contributed what, under which license and making sure every line of code is legit. A lot of engineers don't care about this, but businesses and their lawyers do. A lot of the Apache Foundation "bureaucracy" is to handle this oversight and paperwork.

Git is an impressive tool and github is awesome for what it is, but it's not a non-profit foundation and it won't replace one. Confusing the Apache Software Foundation for your coding sandbox only suggests you don't understand the true purpose of either.

View on HN

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 community but this kind of stubborn attitude will insure that it continues to become irrelevant when it could be a leader.

I do understand the purpose of Apache and it is not hosting source code. That is the point I'm trying to make. If that is not its value, and its policies around hosting that source are no longer beneficial to its projects, then it should change its policy.

I think that you, and many people in the ASF, have married the existing policies of Apache with the purposes for which they were created. While the intentions of the policies may still be relevant, and in my opinion correct, the policies themselves will not remain relevant forever in a field as rapidly evolving as technology and GitHub may just be the first example of Apache policy incompatibility with evolution of open source.

"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 do so. No one will be upset if you, I or anyone else leaves the Foundation. It's cool. We're all here at-will, volunteering effort and code.

Apache cannot be everything to everyone, despite how much it is pulled to be so. Right now it fills a particular important role in the open source and larger software ecosystems. It's in that position due to both historical precedent as well as intentional decisions by the membership body.

But trust me, no one in Apache is ever, ever completely satisfied with the Foundation. That's to be expected -- the organization is driven by the compromises of a large group of people with different ideas and expectations. To balance between the chaos of constant change and the death of no change, the organization has grown guidelines and rules from the collected wisdom of its membership. This gives us at least some framework by which to evolve.

As for hosting code, there have been proposals at time for Apache to push the code hosting to some other organization. Once it was SourceForge, then Google Code, now Github. Of course, it's a tricky situation as the Foundation has particular requirements and wants to know its code will be around for decades. Moreover, infra team is constantly understaffed and thus are a very, very conservative bunch. We've seen way too many people jump in with a great idea and then leave maintenance to someone else. They're stubborn for a reason.

And perhaps Apache and Github are incompatible. So what? Github is a tool. It's incompatible with lots and lots of organizations and ways of doing things. The FSF has its rules and culture. Same with the Linux kernel, distros and desktops like KDE and Gnome. Android is different too. Not all of those mesh with Github and that's fine.

Mikeal isn't arguing that Apache source should be put on GitHub.

He is saying that ASF would benefit from the kind of community development that git promotes as exemplified by GitHub and linux.

Linux is a bad example. It's not "community" development by any real definition of it, because Linus controls everything that goes into the mainline codebase. If anything, it's community maintenance, because that is delegated out.

More importantly, Git by itself does not promote community development. No source control system does. Some make that style of development easier, but none of them actually directly promote it.

GitHub is not Git. GitHub is the Git version of SourceForge. Nearly all the community development features(bug tracking, forums, etc.) on both sites are built beside the source control system, and aren't really integrated directly to either Git or SVN.

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

This is true only from a CYA standpoint. As Mikeal said in the article, it's possible to do a lot of work and build up a strong case for a change that's important to project maintainers, yet still have Apache come up with excuses for why it can't happen. This is what happened with git -- twice.

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.

There's no reason apache can't maintain its own "legally authorative" git repo. Nothing in the authors post suggest that he is confusing the ASF with a "coding sandbox". Making that claim suggests to me that you are invested in the alternative and not thinking objectively.

And I disagree about subversion being "made for Apache in the way Linus made git for Linux". Subversion is an utterly derivative implementation of any server based VCS in existence, where as git is an example of truly creative thought (not just from Linus) about what VCS should be for a large community that requires the accountability that you claim ASF requires.

I'm not totally familiar with the issues here, but from an earlier perusal of the email threads on this, it seems like ASF's concern involves things like git's ability to edit the repository history.

Oh, I can think of a million scary sounding consequences of using git and I'm sure that all were raised. This is what established groups do when confronted with change: raise any objection even though a moments thought demonstrates the paucity of its merits.

That moment of thought was apparently too expensive for you; you didn't respond to the actual concern, but rather raised an argument suggesting that any argument about git must be meritless.

I don't know who you expect to convince by baying at the moon.

The ASF people are right in at least one sense: if you don't want to run projects in the ASF style, you are free to take your work elsewhere.

I need not respond to the actual concern because the ASF has already done so. The ASF has already decided to allow git to be used. I assume that their lawyers OK'd this change. So I did not intend to continue an ongoing discussion: ASF has already concluded that discussion and approved git. Clearly, jaaron does not represent the views of all the "ASF People", and for him to raise issues as legal showstoppers when the lawyers have clearly approved is utterly disingenuous.

The purpose of my post was not to discuss the merit of the git vs subversion argument, but instead to discuss the merits of jaarons criticism of mikeals article.

One method that established groups resist change is to continue to bring back discussion to issues that have been decided. It helps slow discussion on change by making it appear that a previous issue was not, in fact, resolved. In their mind, of course, its not been resolved: the lawyers were wrong, or perhaps the lawyers didn't understand. Established groups don't just get over it and move on. Why would they?

ASF has decided to allow Git. I believe that those projects which use git will enjoy more success than if they use subversion. Mikeal makes some interesting observations about this. Jaaron spouts the traditional establishment bullshit:

1. The other side are children. We are grown ups.

2. Legal implications.

3. Nobody is forcing you to participate.

4. Condescension. "It's impressive for what it is" ... (but "what it is" is "just a sandbox")

I'm calling it for what it is.

> 4. Condescension. "It's impressive for what it is" ... (but "what it is" is "just a sandbox")

You're jumping at shadows and putting words into his mouth. What he said was:

> Git is an impressive tool and github is awesome for what it is, but it's not a non-profit foundation and it won't replace one.

Which doesn't imply the same condescenscion as your "quote".

The very next line:

    Confusing the Apache Software Foundation for your coding sandbox ...

But he does not say "just a sandbox", or otherwise imply that a "coding sandbox" is less valuable than a non-profit organization. They're different things.

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

Without access to the database itself? How?

This is part of git's interface. (I appreciate it and don't think it's a bogeyman, but can see how it could be incompatible with some projects).

As I understand it, if the repo has receive.denynonfastforwards=true, a user can't push changes that will destroy history. This flag has been available since 2006. (And I didn't mod you down. You ask a legitimate question). A bit more research shows that there a couple more config changes required: http://stackoverflow.com/questions/2085871/strategy-for-prev...

I don't think it's easy to do. You can change a commit message, but even that's not easy (you basically need admin access to the repo files).

If you want to edit the contents of the repo I think you need to read > filter > rewrite the whole thing. I could be wrong about this, it's been a while since I thought about it.

Which is utterly trivial (I've done it, seriously, it's not the big deal you seem to think it is, aside from the obvious difficulty of particularly large repos), and is not conceptually different from what's necessary for editing git's history, except that nobody can tell you've done it without comparing the "new" repo to the old one -- and under svn's internal model, no one but the server will normally have a complete history.

With git's model, not only does everybody have the history, but the commit ID themselves are your insurance against tampering. You effectively validate that history every time you sync with another git repo.

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.

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

Yeah, that particular bit of FUD is quite popular with the anti-git crowd. It's nonsense. Any attempt to edit the history of a public repository will be noticed instantly by anybody who tries to sync up, no matter what.

Stick in a post-commit hook to force a sync to a backup repo nobody has access to if you want to be really paranoid, but as it is, git is already far more resilient against tampering with the public history than svn ever was.

Just turn of garbage collection (it isnt instant but i wouldnt bet that it would still be there in six months) and even if you rewrite the history you won't lose the objects. No need for a backup sync

Git normally only allows you to edit unpublished history; the server can prohibit editing of published history. Similarly, svn allows history editing if the server permits it.

See Fedora's git repository for an example of how to do this.

I believe they use gitolite to do this. (https://github.com/sitaramc/gitolite)

In discussion of an article which makes the claim "The problem here is less about git and more about the chasm between Apache and the new culture of open source." it is ironic that an objection is raised that is trivially answered by using one of the very proponents of this new "open knowledge" culture, Stack Overflow:

http://stackoverflow.com/questions/2085871/strategy-for-prev...

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, afaik this is possible by manipulating the database.

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

tl;dr: Sign your Git commits cryptographically with PGP if you don't want the history to be editable.

Git's ability to edit the history is a very useful tool. I don't think Subversion or any other VCS prevents you from editing the history either. Maybe they just don't provide tools for that so you'd have to hack the internal data structures of the VCS or something, but you actually want a tool to modify the history. Think about the situation where somebody accidentally pushed a secret private key or a database password to a public repository, you want it out of there! (there's a ton of examples of this in GitHub. git filter-branch is what you should do).

In order to provide "safe" history for Git, the commits must be cryptographically signed by their authors. This is vastly superior compared to trying to use some server side authentication kludge, which can be broken into. And the data structures of the VCS database can be modified, with a hex editor if all else fails. Cryptographic signing provides a guarantee against hex editor hacking too.

If I read one more "Git sucks because you can edit ancient history" comment from someone who doesn't understand the concept of crypto signing, I will cry.

Discussion on this subject with a reply from Linus:

http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...

You are right, there is no reason why the ASF can't own its own "legally authorative" git repo.

That is exactly why the ASF is conducting experiments in exactly that. Assuming those experiments are a success and representatives of ASF users are happy (which include business folk and lawyers, not just developers) then the ASF will role Git out to all projects that want it.

This whole argument is moot.

Strongly agree with jaaron's post.

I also agree with some of the replies stating that the ASF should do as much as they can to foster contribution and a more active/social community. Perhaps they've just been a bit slow to adopt newer solutions because active contributors are content with the existing setup, and it's not seen as a huge benefit to change this just to be hip with the new crowds every quarter. Either way, it's nice to see Git catching on a bit, since it's one of the most common choices nowadays.

As an organization, the ASF does an excellent job of overseeing crucial projects and the bureaucratic side of programming that comes along with developing services in the enterprise space. With such a large community and range of projects, a degree of bureaucracy is required to keep things running smoothly.

They also do a good job of staying a mostly neutral party and working strongly towards the success of any project they "take in" under their wing. As jaaron noted, they don't actively solicit anything, or go around trying to absorb projects. They simply help maintain the projects that have grown up (and many people rely on).

Being strong proponents of the open web, flexible software licenses, and doing a lot of the paperwork heavy-lifting in the internet and programming industry from a legalese standpoint, I think they do a lot more for the web as a whole than most people are aware.

On the community note, I've run a few Apache community forums over the years, and it always seemed Apache users are starving for more community interaction and very appreciative of the social environment. Many of the Apache projects have a bit of a learning curve to be put into practical use, and people appreciate some guidance in learning the ropes. Maybe the ASF will notice and embrace a larger sense of community as time goes on, or perhaps some of us here on HN can connect and brainstorm something to fill the void.

I think the title of this post was just hyperbole to catch peoples attention regarding a web server vulnerability or newly discovered bug. Haha, seemed to work pretty well.

We're often caught up in the hype of new and catchy-sounding web technologies, but Apache is an organization that helped shape the modern web. Could they perhaps make the community more approachable to newbies? Sure. Are they harmful to the open source movement? I would think not. They bring a lot to the table.

- Chase

The ASF isn't where projects go to "grow up". It's mostly where companies like IBM go to dump their enterprisey Java frameworks so they can be marketed as ostensibly open to outside developers.

Nope, ASF actually provides and enforces a reasonable governance model for projects it adopts.

I wrote something on why this is important: http://bergie.iki.fi/blog/open_source-free_software-what_we_...

While correct, it would benefit Apache in the long run to foster better communities and tools for their projects to grow. While they provide value in terms of the protection/process/management it's all for nothing if the developers can't collaborate effectively.

GitHub has changed many developer's UX of opensource development to the point that they don't want to do it "the old way". Apache should be looking to grow in this direction to keep their developers and projects engaged.

Trouble is, their existing developers and projects seem to be doing fine with SVN. Don't forget those are the most important people, the workhorses you already have- not the flighty young birds you hope to one day trap.

Sure, there is always the future to think about, but the future isn't happening a week from now. They have time to watch Git grow and wait until the time is right.

There's no reason they can't do both at the same time.

And the time to adopt GIT was 2008.

>Trouble is, their existing developers and projects seem to be doing fine with SVN.

This statement has little meaning. If they were still on SCCS and had been using it for years I'm sure they would "do just fine" with it. But if they move to something modern they could do even better.

Except that the existing developers aren't all doing fine with SVN. As referenced in the post, both CouchDB and PhoneGap (existing "workhorse" Apache projects!) prefer to use git, but have met with strong opposition from the ASF.

The time to allow for Git usage is already here. It's not just pie in the sky forecasting -- existing projects are being held back by bureaucracy.

>there are some serious drawbacks for use of git

Such as?

It's not centralized.

I've used centralized SCCSs for years and years. I guess I don't see why you can't use git as one, just have everybody agree to push to a central repository on a server.

There is the issue of the size of the local copy, but it doesn't seem to be a big deal in practice. I just don't check in the heavyweight frameworks as vendor drops into the same repos as I use for my own, smaller, codebase.

Granted, I'm scared to death of ending up in a merge-gone-wrong hell situation trying to do stuff that I'm very familiar with in Perforce. But I'm happy being a git newb taking baby steps a bit longer.

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.

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.

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.

An up-to-date snapshot of my source tree at work is several GB. The whole Perforce repo is probably 100GB. Most of that is vendor libraries. For example, every so often we update to a new version of the Boost C++ libraries and pre-build it for most common platforms. This amounts to a GB or two. This is easier on the other developers and it makes the process more repeatable for QA.

One of the great things about Perforce is that it's normal practice to map only selected subtrees of the repo. So I have several workspaces going at any one time.

As much as I am impressed with git's speed, this would not work with git. I used to try to managing Boost's vendor drop as a git repo. I now just keep my notes in there about how to download and build it locally.

I think the idea is to use git submodules for vendor libs. Anything you're not modifying and a 3rd party is maintaining should be a submodule; that way you don't keep any of those changes in the repo.

When a new vendor release comes out, we build it with our "official" compiler settings for the different platforms, branch the headers from the source and combine them into a convenient "SDK" tree, sometimes tweak something here or there, and update the document. Amounts to several GB being checked in from multiple machines. Occasionally a developer (usually me, but others too) needs to commit changes back to our central repo vendor tree.

I suppose we could do that into a separate repository and then define parts of that as a git submodule.

Hmm, reading http://book.git-scm.com/5_submodules.html I don't see how to do that with git without using 100 GB on the library dev machines.

You can, but SVN more or less forces you to.

Which means that if a developer wants to do do git-like stuff (say sharing a patch with a single other developer or committing a day's unfinished work to an alternate backup site), then he's just going to have to work around the SVN tool to do it.

The tool should exist to serve the people producing the work, not the other way around.

>>there are some serious drawbacks for use of git

> Such as?

The more important question is: what are developers really missing when they have to use svn to hack ASF's code in comparison to using git? (leaving github out of the equation, it is not git) You can hack locally to your heart's content and in case you want to contribute, you can diff and contribute.

I don't really see the problem.

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.

>I don't really see the problem.

Part of the drive of open source is bootstrapping better ways of doing things. We could all likely do our jobs to some degree running Windows 95, but who wants to? Git improvements over SVN include increased performance, cheap branching, more detailed tracking of changes, the ability to code offline (not a huge deal, but it certainly has made traveling more fun for me), and DVCS collaboration capabilities.

It's complicated.

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.

Hey, I work at the Wikimedia Foundation -- a non-profit -- and we're eagerly anticipating a switchover to git. I don't see what one thing has to do with another.

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?

Ironically, http://git.apache.org is not responding.

There is also a mirror on GitHub: https://github.com/apache

I would put up node.js as a counter-example. It is a large, important project successfully being managed on github. It's sponsor, Joyent, is a private company, but the role could easily be filled by a foundation like Apache.

There's actually not a lot to cover here? The question is why you're so scared of git and in six paragraphs you managed NOT to answer that question. This is really sad. One might hope an open source fondation would be forthright and fairly transparent. Apparently not.

Uh, I linked to the official git repos for Apache. Apache isn't afraid of git. Plenty of Apache people love git. At the same time there are issues with implementing and supporting it by the ASF infra team. If you want all those details, search those mailing lists.

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 - and they have only grown from there, so no wonder a project hosted on github now is more "fun" to contribute to and work with because processes are probably pretty much non-existent and communication-paths and hierarchies are pretty much flat. The same goes for working at a small start-up vs. working at HugeFatCat Inc.

But one thing I cannot stand: arguing git over subversion. Yes both are great revision control systems but they are just meant for different applications. Where I am working, I would take subversion over git any day if all I really want is an absolutely sure-fire way of having a simple and easy to use central repository. I am in the unfortunate position to having met and working with quite a few people (programmers non-the-less) who have a hard time coping with basic CVS/SVN update-commit cycles - with git and mercurial offering you the option to commit but to your local changes first before actually committing your changes to the repository you checked out from (or another repository or...), this would have literally created havoc and confusion for my small team here... I know them, yes it sounds ridiculous, but I know I have saved myself a hell of a lot of trouble and headache. SVN is an absolutely perfect tool for the job if you do not need the de-centralization, on-the-go-commits and all the possibilities of creating custom processes in git with all its flexibility and features and options. SVN works just fine for what it is.

git and mercurial are not better,newer,shinier substitutes but different beasts altogether. (great, shiny, powerful and useful none-the-less) So could be please just let them peacefully co-exist and be thankful someone made them for us to make our lives easier?

I am sorry to tell you, but you are plain wrong! Git is better. The problem is that SVN embraces a workflow that is inferior. But if you are not willing to change your workflow, git will seem confusing, indeed.

> 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 makes it inferior?

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

You describe my environment almost exactly. I am pushing for a git migration mostly for the low-overhead branching/merging as I can have multiple discrete tasks on a given project which need to be rolled out individually.

Don't forget speed. Git is fast.

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 create clean commits and push them to trunk.

E.g., I want to make module Foo, and use it in Bar. I can use git as I go, building module Foo incrementally over 5 commits (none of which has sufficient quality to go into trunk). Then I can do 5 more commits which integrate Foo into Bar. So my individual history is tracked while I'm developing. If, while building Bar, I make a bugfix to foo, I can commit it.

So logically, my commits look like:

101-104 Work on Foo

105-107 Work on Bar 108 Bug fix on Foo 109-111 Finish work on Bar

When it comes time to push to trunk, I can rebase 101-104 + 108 into one clean patch, "Built module foo", and 105-107 + 109-111 into "Incorporate module foo into bar". Then I eventually push these into the main repo.

Further, if I'm working on this with someone else, we can use git to track work between the two of us without committing to mainline.

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

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

Because with svn you end up having dirty working directories that go uncommitted for days because committing would break the build, as a result:

1. Everyone ends up making a second working directory because the first one they have is dirty with changes they can't yet commit and they need to make a quick change

2. Those dirty working directories are branches in practice, even if svn doesn't call them that, they are just dealt with with inferior tools.

Also: cherry picking commits from a branch into another branch isn't as easy, making a new repository isn't as easy, git is way faster at (almost?) everything (including large binary files), and being able to check the history when you are not in the office or connected to the VPN is nice.

However, I agree that the conceptual model behind DVCS is harder to understand, significantly harder, svn can be good enough especially for a small, local team.

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

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.

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.

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

Spot on the "coping" with update/commit cycle - I have exact same problem in my team.

You have my full sympathy... we are doomed :(

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 to develop a fucking operating system or the worlds http server.

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.

I am not sure what the use case differences are. To me, git is simply a better version of svn.

Reply on news.ycombinator.com