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 re
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.
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: (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 re
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:April Fools! (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!