I've never understood the popularity of git. It may be useful for open source by supporting distributed development but it seems far less useful for a traditional corporate environment. SVN just makes far more sense to me in terms of command structure. If I wanted a DVCS I would probably go with Mercurial. Git is just awful.
Disagree. I've seen Git used to good effect in a traditional corporate environment. The ability to quickly make your own branches is useful, even if there's just an SVN-style single trunk of proper code-reviewed commits. (Technically, as Git is SVN compatible, so you could get this effect simply by using Git 'locally'.)
The ability to make team-specific branches is also valuable: a team can work toward a feature using a team-local branch, and only once they're done, rebase and push their work into the the tr
I use Git to good effect in a fairly traditional corporate environment. We're much better off since switching over from SVN.
Never mind the 'distributed' part - the big challenge for source control in a traditional setup is when two people have both modified different parts of the same files, and the second guy goes to check in. Git is much better at handling conflicts than SVN is - conflicts that would cause real pain in SVN often merge smoothly in Git.
It's also much better at handling branches, e.g. a release branch. Remember 'tree conflicts' in SVN? Not an issue in Git.
Git is a better SVN, as well as being a distributed source control system.
I keep hearing this, but so far I have encountered about the same amount of branch conflict in git as I have with SVN, just with the added complexity of local repo vs checkout. But I have not found any magical advantage in its ability to merge a file that has been changed by two different developers.
Ha! I see just the opposite: git fucking up miserably to the point where a dev has to locally pull their changes, reclone, and overlay the changes... where svn I have never seen that.
Of course when the network goes down, so does svn.... choose your poison.
Try deleting a local folder without deleting the subfolders (and committing) first. Instant corruption in SVN.
Move a folder (with subfolders). Instant corruption in SVN.
Since Git (and Hg) do a diff of the entire checkout rather than maintaining meta deta per directory, it's a lot easier to do refactoring without screwing things up.
TortoiseSVN (for example), right click drag, drop, select SVN Move versioned files here. That was exhausting.
So much worse than when, say SmartGit, gets stuck in an endless rebaseing state thereby complete fsking your local repo along with any stashes you may have.
But this is what you get for replying on a GUI.
However most GUI devs I work with (myself included) operate from the command line.
You are almost certainly using git wrong. The benefit comes from the ability to keep feeding out changes to the main branch much faster. You don't magically find merges of to the same place easier but you find that they happen much less often because your changes are already out there.
The fundamental philosophy here is merge early, merge often which is much better supported in git than any other tool.
I keep hearing the "git is better than svn at handling conflicts" meme, but of course neither handles conflicts at all. A conflict is a file where the tool can't figure out how to merge two versions and therefore has to offload it to a human.
I've also heard on the Internet that git is better than svn at doing merges, but everybody I know who has used both git and svn in real production environments says the opposite.
In my company we use svn. I did consider moving us to git or - more likely - Mercurial (th
One way to make your old car run better is to look up the price of a new model.
April Fools! (Score:1, Troll)
Subversion is really a joke. Gotcha!
Re: (Score:5, Insightful)
I've never understood the popularity of git. It may be useful for open source by supporting distributed development but it seems far less useful for a traditional corporate environment. SVN just makes far more sense to me in terms of command structure. If I wanted a DVCS I would probably go with Mercurial. Git is just awful.
Re: (Score:5, Informative)
Disagree. I've seen Git used to good effect in a traditional corporate environment. The ability to quickly make your own branches is useful, even if there's just an SVN-style single trunk of proper code-reviewed commits. (Technically, as Git is SVN compatible, so you could get this effect simply by using Git 'locally'.)
The ability to make team-specific branches is also valuable: a team can work toward a feature using a team-local branch, and only once they're done, rebase and push their work into the the tr
Re:April Fools! (Score:4, Insightful)
I use Git to good effect in a fairly traditional corporate environment. We're much better off since switching over from SVN.
Never mind the 'distributed' part - the big challenge for source control in a traditional setup is when two people have both modified different parts of the same files, and the second guy goes to check in. Git is much better at handling conflicts than SVN is - conflicts that would cause real pain in SVN often merge smoothly in Git.
It's also much better at handling branches, e.g. a release branch. Remember 'tree conflicts' in SVN? Not an issue in Git.
Git is a better SVN, as well as being a distributed source control system.
Re: (Score:3)
Branching does not seem any harder or easier.
Re: (Score:2)
The difference I've seen is that Git doesn't fail miserably and corrupt your local repository tracking info the way SVN tends to.
Re: (Score:2)
Ha! I see just the opposite: git fucking up miserably to the point where a dev has to locally pull their changes, reclone, and overlay the changes... where svn I have never seen that.
Of course when the network goes down, so does svn.... choose your poison.
Re: (Score:2)
Try deleting a local folder without deleting the subfolders (and committing) first. Instant corruption in SVN.
Move a folder (with subfolders). Instant corruption in SVN.
Since Git (and Hg) do a diff of the entire checkout rather than maintaining meta deta per directory, it's a lot easier to do refactoring without screwing things up.
Re: (Score:2)
It is true, you must use "svn mv" as opposed to "mv."
The horror.
Re: (Score:2)
Yeah, try teaching that to people who's job is to do front-end development or other tasks where the OS GUI is the right tool, not the command line.
Re: (Score:2)
TortoiseSVN (for example), right click drag, drop, select SVN Move versioned files here. That was exhausting.
So much worse than when, say SmartGit, gets stuck in an endless rebaseing state thereby complete fsking your local repo along with any stashes you may have.
But this is what you get for replying on a GUI.
However most GUI devs I work with (myself included) operate from the command line.
Re: (Score:2)
Replying on a GUI. Jesus wept.
Re: (Score:2)
Or you know, just drag and drop using my existing filesystem viewer and not need a special client to do something simple like renaming a folder.
Nothing like reinventing the wheel!
Re: (Score:1)
You are almost certainly using git wrong. The benefit comes from the ability to keep feeding out changes to the main branch much faster. You don't magically find merges of to the same place easier but you find that they happen much less often because your changes are already out there.
The fundamental philosophy here is merge early, merge often which is much better supported in git than any other tool.
Re: (Score:2)
I keep hearing the "git is better than svn at handling conflicts" meme, but of course neither handles conflicts at all. A conflict is a file where the tool can't figure out how to merge two versions and therefore has to offload it to a human.
I've also heard on the Internet that git is better than svn at doing merges, but everybody I know who has used both git and svn in real production environments says the opposite.
In my company we use svn. I did consider moving us to git or - more likely - Mercurial (th