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 trunk. (Yes, rebasing might take work, but it can be beneficial to just 'do this all in one go' when the team is done implementing the feature, as it means the ground isn't moving beneath their feet during 'proper' development time.)
Git does everything SVN does, and an awful lot more - personally I'd only even consider going with SVN if there were a developer team who only knew SVN and didn't have time to learn Git.
Don't know much about Mercurial, but I'm sure it's good too.
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
(Technically, as Git is SVN compatible, so you could get this effect simply by using Git 'locally'.)
git2svn has a problem that we ran into recently: because git does not support hierarchical branching, if you do not keep all your branches in a single Subversion directory, it will take an excessively long time for a local git repository to synchronize with a Subversion repository.
For example, let's say that you have the typical/branches directory in Subversion. Now user "myria" comes along, and she wants to make her own directory of branches so that her own branches don't pollute the/branches directory.
git does support hierarchical branches. You can have a branch named maria/new-crypto, and even pattern-match on the branch path in refspecs. The problem, as you alluded to, is that SVN doesn't have native branches at all, just copies. How is git-svn supposed to know that/branches/maria/new-crypto refers to a branch of/trunk and not to a directory within the "maria" branch? They look the same. For that matter, you could get that path by creating a branch named "maria" (copied from some version of/trunk) a
Pull requests are also massively useful for a corporate environment. They allow you to easily integrate code changes from teams (or contractors) that don't have write access to the origin repo.
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:April Fools! (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 trunk. (Yes, rebasing might take work, but it can be beneficial to just 'do this all in one go' when the team is done implementing the feature, as it means the ground isn't moving beneath their feet during 'proper' development time.)
Git does everything SVN does, and an awful lot more - personally I'd only even consider going with SVN if there were a developer team who only knew SVN and didn't have time to learn Git.
Don't know much about Mercurial, but I'm sure it's good too.
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
One big way in which Git is not SVN-compatible (Score:2)
(Technically, as Git is SVN compatible, so you could get this effect simply by using Git 'locally'.)
git2svn has a problem that we ran into recently: because git does not support hierarchical branching, if you do not keep all your branches in a single Subversion directory, it will take an excessively long time for a local git repository to synchronize with a Subversion repository.
For example, let's say that you have the typical /branches directory in Subversion. Now user "myria" comes along, and she wants to make her own directory of branches so that her own branches don't pollute the /branches directory.
Re: (Score:2)
git does support hierarchical branches. You can have a branch named maria/new-crypto, and even pattern-match on the branch path in refspecs. The problem, as you alluded to, is that SVN doesn't have native branches at all, just copies. How is git-svn supposed to know that /branches/maria/new-crypto refers to a branch of /trunk and not to a directory within the "maria" branch? They look the same. For that matter, you could get that path by creating a branch named "maria" (copied from some version of /trunk) a
Re: (Score:1)