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
(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. She does an svn copy of/trunk to/branches/myria/new-crypto. Now git2svn tries to import this change from Subversion into a local git repository and takes three hours. Why?
Because git doesn't support hierarchical branch names, from git's naive perspective, what Myria has done is make a copy of the entire repository into a new directory named "new-crypto" inside of her "myria" branch. Git does not interpret her commit as a creation of a branch - it sees "myria" as the branch, and "new-crypto" as merely a directory within the branch. Subversion gives no special meaning to the directory named "branches", so git2svn is simply using a hack of assuming that the "branches" directory contains objects that it can convert into git's branch objects. Git thus sees her commit as one giant commit of 100,000 files, and consequently takes forever processing it.
The above was a recently-encountered real-life situation at the office from about two weeks ago.
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
Never worry about theory as long as the machinery does what it's supposed to do.
-- R. A. Heinlein
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
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. She does an svn copy of /trunk to /branches/myria/new-crypto. Now git2svn tries to import this change from Subversion into a local git repository and takes three hours. Why?
Because git doesn't support hierarchical branch names, from git's naive perspective, what Myria has done is make a copy of the entire repository into a new directory named "new-crypto" inside of her "myria" branch. Git does not interpret her commit as a creation of a branch - it sees "myria" as the branch, and "new-crypto" as merely a directory within the branch. Subversion gives no special meaning to the directory named "branches", so git2svn is simply using a hack of assuming that the "branches" directory contains objects that it can convert into git's branch objects. Git thus sees her commit as one giant commit of 100,000 files, and consequently takes forever processing it.
The above was a recently-encountered real-life situation at the office from about two weeks ago.
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