Judgment is not the end of the world, and it is not a reflection upon one's character to say that something is better than the tool one currently uses. In other words, it's alright to say that git is better than SVN. If it weren't we wouldn't have all stopped using SVN.
>If it weren't we wouldn't have all stopped using SVN.
I like git fine, but judging quality by where the crowd is running is like flipping a coin.
edit: Fine. We're just going to substitute pith for basic reason here, I guess. Because the industry has largely moved to git, it's clearly the superior tool, and those who don't accept that are clearly emotionally blocked. Or not.
In Linus Torvalds' talk on git at google[0], he mentions that the reason why he did not choose SVN (one of the reasons why he saw no other way but to build GIT) was that SVNs mission statement read "To create a compelling replacement for CVS"... which Linus hated with a passion and thus could not see why he would even use "a compelling replacement" of.
Interestingly enough, in the 'Open Source projects and poisonous people' talk[1] with two SVN developers, they mention how they chose that line specifically to make sure that everybody is on the same page with the scope of the project - improving upon what people knew and were used to instead of wild, new things. Specifically because they would often have people come into the community with some grand plans that would have just exploded the scope.
It is of course arguable to what extent there could be a general rule to this, but in this case, GIT is just so fundamentally and obviously the better option than SVN. Had somebody tried to make SVN into GIT, it would have simply killed SVN, so it was the right course of action to make it a new project. SVN was destined to die by its design.
To see the GIT adoption rates these days (particularly due to tools like GitHub) is very encouraging to people who like to think that sometimes, starting over fresh is the only option. Of course, the thing you want to build really has to be that much better than the old thing you're trying to replace.
So I agree with you - it's alright to say that GIT is better than SVN. The crucial point to me, though, is that it is so much better. So much better that it is worth the effor to build and worth the effort of the community to switch.
In Linus Torvalds' talk on git at google[0], he mentions that the reason why he did not choose SVN (one of the reasons why he saw no other way but to build GIT) was that SVNs mission statement read "To create a compelling replacement for CVS"... which Linus hated with a passion and thus could not see why he would even use "a compelling replacement" of.
Having experienced the workflow they learned from using another DVCS (Bitkeeper) probably also influenced his decision at the time.
Before even clicking the SO link, I knew this question was closed as off-topic ...
How about they make a dedicated space in SO where this kind of questions are allowed.
I don't mean a free for all, but a heavily moderated part where you can ask recommendations from your peers about the best framework / book etc as long as it's related to programming.
Edit: Although it would be great if SO suggested moving discussions there, instead of just closing as off-topic. You can close-move questions that belong to superuser.com for example.
Well, around half of the questions on programmers.se break at least 2,4,5 without any issues. Like "How to manage accidental complexity in software projects", "Why would I use Angular?", "Would Python be too slow for client-side use in Browsers?", etc. I've never seen a similar question closed on programmers.se, even they don't respect all of those points.
It's been around for ages perhaps, but for a long time has not caught on. Most of the time when I search google for a question that might be appropriate for programmers.stackexchange.com, I wind up with links to locked topics on stackoverflow instead. None of them even include references to SE:programmers. The difference in site volume is telling as well. Quantcast gives stackoverflow 11.4 million uniques per month, while programmers.stackexchange is only 400,000.
The distinction seems clear from 60,000 feet but sorting edge cases seems to depend largely on capricious and arbitrary moderation. And practically speaking, in many cases you would actually get better answers on stackoverflow, but for the oppressive moderation.
Which is an... interesting set of choices. I'm not sure why you can't suggest others. I'd really like to migrate to programmers.SE. Otherwise the only option is to actually close as off-topic.
THe list of choices you can vote to move to is based on where questions are migrated most of the time. Moderators can still move the question wherever they want, just flag for attention and give a custom message to that effect.
Is that the ability of the diamond-by-the-nick mods only? http://stackoverflow.com/help/privileges?tab=all doesn't list it explicitly and it's definitely not a part of "access to moderator tools".
Correct. Site (diamond) moderators can move a question to any stackexchange site of their choice. Source: I'm a moderator for http://android.stackexchange.com
I used to be pretty heavily involved with the meta of p.se early on. The policy you suggest is exactly what SO users really wanted, but p.se rejected the idea because it would mean that they would become a dumping ground for bad SO questions. It actually became a bit of a dumping ground before implementing some very aggressive moderation.
> but a heavily moderated part where you can ask recommendations from your peers about the best framework / book etc as long as it's related to programming.
This has been asked before on HN and my response is generally "no". First, the idea of SO is that it provides a QA format so that you can reference it later. If you watch Spolsky's talk about how they built the community for SO was built, he specifically mentions "SO is not for the person answering the question or the person asking the original question, it's for the hundreds of other people who ask the same question a hundred times again". In theory this means if I want to know how to (example) "split an array in Ruby v1.9" the answer is and always will be "<insert answer>". Your answer to "here are my requirements for a new facebook startup, tell me what frameworks work best" is going to go in 100 directions and even if one answer is "the best" it doesn't mean 3 years from now that that answer will still be true. If you think about it you can easily see how much of a wasteland that would become.
But it's just these kinds of qualitative discussions that people crave to make major decisions on project directions. Without a quality discussion of pros and cons for different scenarios how are you to make a reasoned decision? Thousands of people probably have these kind of questions versus the smaller number for very esoteric problems. Time invalidates whole classes of answers as new releases are rolled out. SO should make a space for these kind of purposes, even if that is a separate space.
Git is the right tool for: branching and merging. And for cherry picking bug fixes from disparate branches.
The git workflow revolves around creating a branch for a feature or bug fix. Because in Git, branching and merging is cheap.
I've switched from a decade of using SVN, to Git and it is more than a shiny new tool. It is the right kind of tool for the above.
In SVN, branching and merging is expensive, and if the changes between branches were extensive enough.. the merge process would take a good weekend of manual effort. In some scenarios almost impossible to do. And in some shops I worked at, a branch with 3 months of differences would take a week to merge. SVN is not the right tool for this.
By contrast, my job is a much better usage case for SVN. We have only three developers, a single trunk, and rolling production deployments. We're never concerned about release or feature branches or back-porting fixes. SVN is the right tool for this. Git's extra abstraction layer around decentralization and distribution would just get in the way. I have used git in a previous job and for personal projects to get something up on Github, and I haven't yet missed it here in our SVN shop.
Git is like applying an N log N solution to an algorithmic problem. Great for something that in the naive case would be N² (N branches exchanging updates with each of N branches), but when the problem space is very small, whatever layer represents the log N is just overhead.
Even as a single developer, I find the effortless branching in git a killer feature. Even with the poor (from a human perspective) implementation of EGit in Eclipse, the ability to experiment in branches while preserving a "last known good" point would be hard to give up.
Add to this the effortless sharing and "cost-less" review provided make git a clear winner.
> This looks good at first, but just keep in mind the added complexity to this approach.
I think this is not exactly right. The approach is fundamentally different but not more complicated. I think that the one important concept of Git is that everyone has a complete copy repository, making the communication with a server (through SSH, HTTP or the Git protocol) just an additional feature: the very core of Git does not depend on anything.
It is more complicated, and the complexity buys you (assuming you need it) an ability to relax certain limits of more traditional SCM solutions.
To be honest I don't find git to be better than svn for a lot of work, having worked with both. There are fundamentally different decisions made, such as:
1 it is a lot easier to forget to add a file in svn, but it is a lot easier to accidentally include a file you don't want in git.
2 workflow in svn is a lot more streamlined because you aren't dealing with a multi-stage synchronization between your repositories (I am assuming the reason you use version control is in part to collaborate).
Now, one thing I have started to get really into has been the combination of github and svn, which gives you a lot of the benefits of svn and git together. Now, it doesn't give you every benefit of git but it gives you enough of them to make things easier all around in many cases.
2. svn commit -m "commit message" (ok, I add an svn up && before, but I consider that one step).
done
Workflow with git:
1. Edit some files
2. git commit
3. Review the message to see which files I actually want to add, if there is anything that needs to go into git ignore, etc.
4. Edit .gitignore as necessary
5. git add *
6. git commit -m "commit message"
7. git push
So for simple cases you have 3 times as many steps, for more complex cases you have more steps. Note that I usually push/pull from my own github repo and not a central one because that avoids a lot of other hassle (and then use pull requests for managing inter-repo changes, something github has done a nice job with).
Additionally absent this you have a significant likelihood that you end up with various files that aren't a part of your build environment (generated makefiles, backups of generated makefiles, built packages, etc) accidently pushed out to your central repo.
That's still a lot more verbose than svn and even if you do that, you still have only managed to reduce the number of commands required from 3x to 2x what svn requires.
Also wouldn't you agree that git has a much steeper learning curve than svn? What is this due to if not the added complexity?
It is also important to note that the git tooling has matured a lot over the years. In the beginning, people used wrappers such as Cogito - "Human-suitable Interface for Git"[1] because the command line interface was such a pain.
Serious question: How/where do you check in your binary builds and debug symbols if you use git? I've read it's not great at some not-so-large project size. I'm using SVN on a micro-sized team with binaries from all released builds safely checked in (which means the repository is probably 100GB-ish in size), and it works great. [and to head off the argument - rebuilding from source is not an option when you have to diagnose a customer crash when they are using a 3 year old build of the software - you'd have to archive a build machine to even have a chance...]
Why wouldn't they? Conveniently and safely in the same location as the code they were built with. Tagged the same way. Having a separate repository is just inviting trouble down the road, no?
Because they're binary files, used entirely for archival purposes. They shouldn't be changing, they shouldn't have "versions" that are anything to deal with meaningfully as far as your repository is concerned.
They should be in flat storage somewhere, with some directory or file name scheme that makes sense based on your version numbers / builds / what have you. Backed up, (ideally) with hashes that verify that they're the same file they once were.
As said above: Git adds complexity. Two modes of creating repositories, checkout vs. clone, commit vs. push... You have to know which commands work locally and which work with "the server" (I'm assuming most people still like a central "master-repository").
...
Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. Also, it's much faster than SVN. And from what I hear, branching and merging support is a lot better (which is to be expected, as these are the core reasons it was written).
Perhaps that is a little harsh. I think the poster just doesn't understand DVCS's.
The whole point of a DVCS is to be decentralized. Linus Torvalds often just posts his own repository and others pull from it.
You can use it as a centralized repo, and it works quite well. In fact, it's how I'm doing development with LibreOffice via gerrit. However, even there I find it easier. I find my workflow is to work on a branch, make sure I have clean commits (I use rebase pretty frequently) and branch and merge often. Frankly, it's easier to work with. I find the staging model to be really excellent, and find it just easier to move up and down commits.
But looking at the quotes:
Git seems to be the "new, shiny, cool" thing.
No, no it's not.
Two modes of creating repositories
Well, sure. It's literally just a shortcut for setting up groups and then changing a global setting. Repos can go from bare to shared reasonably easily. I fail to see the point.
checkout vs. clone
Checkout checks out a branch of path to the working directory. Clone gets an entire repository and "clones" it to the current directory. There is no "versus" here, they are two completely different operations.
commit vs. push
Commit records the changes to the local repository. Push basically takes a ref (a mapping to a sha-1 value that identifies a commit in the tree) and updates a ref in a remote repository. In essence, you are pushing your changes to the remote repository. Again, the thinking of a VCS person, not someone used to DVCSes.
You have to know which commands work locally and which work with "the server"
Only if you think in terms of centralized repositories. A DVCS is distributed. It's a completely different way of thinking. I find it superior in very many ways.
Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository.
The whole point of git is that you have your version, and you either pull from or push to different repositories and and when needed. The whole idea of centralization is not core to it at all.
> Only if you think in terms of centralized repositories. A DVCS is distributed. It's a completely different way of thinking. I find it superior in very many ways.
The benefits come at a cost though (I say this as someone who works with both). For many environments, a centralized VCS is all you need. Making it distributed just because that's a popular thing to do isn't necessarily always a good idea. It complicates workflows because now you have to have multiple version control systems which interact with eachother in far more complex ways. You don't want to go down that path if you don't need to.
Now, despite the costs, there are many advantages to git. These include an ability to effectively treat your local repo as a master for a client. Also DVCS's scale to a larger number of developers more than traditional VCS's and git has advantages there too.
BTW. one thing I find to be a killer feature of github is the fact that it offers you svn access to git repos, which can be really, really nice.
> The benefits come at a cost though (I say this as someone who works with both). For many environments, a centralized VCS is all you need.
I'm having a hard time understanding what these extra "costs" are. I haven't used SVN in a while, but I think the only extra cost is an extra command to push your changes to a repository.
Meanwhile, the advantages of a distributed VCS are huge. Even if everyone is developing on the same LAN it seems beneficial to have a DVCS. I've been on multiple projects where the centralized VCS goes down for a day or even a week. In that scenario everyone has to stop committing changes. Sharing changes with a coworker now requires making a patch file or some other cumbersome operation.
I can't think of a situation where a centralized VCS is better for any team.
I just find I end up spending quite a bit more time fighting with git than I do svn. It may be anecdotal, but I find my workflows are far more error prone in git, and consequently they take a lot more overhead to ensure they are right.
What you say might be true by at least accepted theory, and it is true that command-line git (and git has a reputation of a bad command line) is the only dcvs I have worked with but I don't see a way around the fact that since you allow more complexity in interactions between repos, this is going to have more overhead. Even you seem to acknowledge twice as many commands for version control management for the simplest cases.
I am not really anti-git even. As I say I use it for some things. But I am not at all convinced dvcs is always the right tool for the job.
> Even you seem to acknowledge twice as many commands for version control management for the simplest cases.
Well, I didn't really say that regarding the simplest cases. There is one extra command to get something into the central repository, but basic checkouts and updates from the repository are still one command.
I've gone through the "fighting" with git stage, but it was more because I was trying to use concepts that aren't even possible with SVN rather than that git makes things more complicated.
Indeed - which system is best depends on your workflow. For small to medium teams structured in a top-down business way, svn is easier to understand. git generates a lot more merging (every pull is a merge).
A distributed VCS is very useful if you have a distributed team. If you don't, the distributed aspect is simply not very relevant.
Well, no. If you have a centralized git server (can be done), then you have the following workflow:
1. Make your changes, branch, do whatever you want to do.
2. Commit the changes to your repo.
3. Push your changes to the remote repo.
4. When you want to get other's changes, pull those changes. Heck, do a git pull -r if you want to rebase them.
That is really not that complicated. However, you get the benefits of a local copy. So not what I'd really call totally distributed, but I can't see any downsides to this.
It's still twice as many steps. Well, probably more if you count git add before every commit.
Also a big problem for me is the necessity of a git add * before a commit, which effectively requires a lot of management of .gitignore so you don't get things like the Makefile.old getting committed. Keep in mind, all of this is process overhead, an opportunity to make mistakes, and effort (including tracking/fixing the mistakes) that could be spent programming.
There are downsides. As I say, I do a fair bit with both and to be honest I am not that enthusiastic about git over svn. It's really good in some cases. However it isn't always better. Sometimes simpler tools are better.
Personally (as a near-beginner) I have no end of trouble with the push/pull workflow. You can't pull if you have files edited, but you can't push if you're behind. 'git stash' makes this a bit less painful.
I'm a bit annoyed at how the discussion here has turned out. Did you actually read the post you're criticizing instead of just jumping at the first critical points he makes about git because it happens to be your favorite tool? No argument you list here is in any way contradicting to what the post says.
To summarize again, the post says: Git is more powerful because it's distributed - but that comes at a price in terms of a more complex UI. If you know that you'll never need DVCS, you might be better off using SVN.
Everything you are listing here is examples of how git's UI is more complex, except you don't seem to recognize it anymore because git has become so engrained in what you do. Every so often it's worth it to take a step back, to look at our workflows and to figure out why we do what we do for every step. This SO reply was IMO a good attempt at explaining exactly this in terms of the Git vs. SVN discussion.
I'm a bit annoyed at how your response to me has turned out. Did you actually read my response which you're criticizing instead of jumping at the first "critical points" I make about the comments made about git by the user? Or is it because git is not your favourite tool? No argument you list here is in any way contradicting what I said.
Yes, I did indeed read the post. I wasn't jumping at "critical points", I was pointing out that he doesn't seem to have his head around a DVCS like git.
As I've pointed out a few times, the UI is not really more complex. There is literally one more step - git push - to have your changes "pushed" to a remote repo.
I'll not edit the above reply. But I'm sorry I wrote that the way I did. It was very snarky and unnecessary. Apologies for bringing down the tone of the thread. :(
I think what you're missing is DVCS is a subset of "version control". A large percent of developers have moved from CVS to SVN and for the past few years are hearing Git is the successor to SVN. So they are comparing the new hot version control Git to their previous SVN. A lot of these people don't care about the distributed aspect, just whether git is better than svn for their version controlling needs.
I think the thing that generated much of the initial git confusion for svn users was a lot of the git documentation at the time were devoted to using git in a very distributed, very branching, type of of manner, which while it's awesome that it's possible, is needless complexity for many dev teams. Particularly this post was passed around as the gold standard: http://nvie.com/posts/a-successful-git-branching-model/ .
A lot of svn devs were used to a pretty simple work flow. Checkout the current branch in dev, make some edits, commit/push. Rinse, repeat. On many teams no one other than the lead dev/release master would ever need to even do a merge. Now show this team the above git branching model, which suggest Bob can pull a feature branch over from Alice, make some commits and push back, but wait Sam has also needed to pull Alice's to make some commits, and merges in her latest changes from Develop which conflict with both Bob and Alices current. Now you have the lead dev or release manager wasting hours trying to figure out this merge mess with 3 broken repos and the PM demanding Sam's changes in develop are needed for a hotfix by Pat yesterday. I hope you can see the massive complexity increase in the way a lot of teams were initially told to use Git.
Once people figured out everyone could pull and push from a centralized repo (Github heavily helped this) and that branches should (for a certain type of dev team) always be pushed/pulled from the central repo instead of shared peer to peer, the workflow was much simplified. Git with a central repo is more than likely better than using svn for many teams. The easy branching and offline commits are benefits whether a team needs the "distributed" aspect or not.
It's apparent that you really understand and use a DCVS, many people do not. It's important to realize on many projects devs don't want or need to become experts on DCVS, but could still benefit from using Git over svn. For a lot of open source projects, merging and reviewing patches is a big part of the project as that's how new code gets in. For a startup team, any time spent on dealing with a VCS system is time not spent developing the product.
You make some interesting points, but I suppose that I take issue that branching is a particularly complex thing. IMO, branching allows you to make changes without affecting the mainline code, then the merge points allow you to get back to contributing back to the codebase.
I think it's odd though that you use the example that someone checks out the current branch, makes some edits, then commits back in the changes. You have the same problem you highlight - if someone else makes changes, then you get the same merging issues, only this time it's on the main branch. You will still get the same project managers screaming for a hotfix, and you'll still get the same problems of merging in the changes that were checked out. After all, SVN doesn't prevent others from checking out the same files and commiting changes whilst you are making changes.
BTW, what do you mean that a DVCS is a subset of version control?
Drawback: if you are storing a lot of binary blobs, it will balloon the size of a git repo quickly if those objects change often. While with SVN, users only have to download the latest.
To add: there is a reason most game development shops use Perforce. Sometimes you have to deal with large binary assets. Git is just the wrong answer in that case.
Why are Pink Lady apples better than Granny Smith apples?
Why is being an omnivore better than being a vegetarian?
The way you answer all these questions will be the same. So whether you have an answer or a process to answer these questions, you'll have a pretty good idea about git vs svn.
The form of the answer may be the same, but not the content. The idea that answers are subject to preference and different needs doesn't mean a question can not have objective answers.
