6 ms·
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 AS
by kahawe 15y ago
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?
- ma2rten 15y agoI 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.
- kahawe 15y ago> 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?
- fuzzix 15y ago"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.
- RyanMcGreal 15y agoDon't forget speed. Git is fast.
- deleted 15y ago[deleted]
- yummyfajitas 15y agoIn 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.
- jimbobimbo 15y agoSpot on the "coping" with update/commit cycle - I have exact same problem in my team.
- kahawe 15y agoYou have my full sympathy... we are doomed :(
- buff-a 15y agoSo 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.
- kahawe 15y agoDid 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.
- kiba 15y agoI am not sure what the use case differences are. To me, git is simply a better version of svn.