Paul, Git branching is faster, computationally cheaper, and requires less disk space than svn branching. This link provides more information: https://git.wiki.kernel.org/index.php/GitSvnComparison.
In git, you have a remote repo, and a local repo. Typically, people create local branches for experiments or new features and then merge and create pull-requests whenever they have something that they want to share with the community. In svn, whenever you branch, you're branching on the server first. Usually, if you're new to a code base, you don't want to do that if you're just experimenting. Ideally, you want to encourage experimentation (and attract new developers), so "feature branches" make a lot of sense in that context. Cheers, Mark On Tue, Sep 9, 2014 at 10:46 AM, Paul Benedict <pbened...@apache.org> wrote: > Mark, can you help me understand why git branches (the "feature" branch) is > better than an svn branch? > > > Cheers, > Paul > > On Tue, Sep 9, 2014 at 10:57 AM, Mark Fortner <phidia...@gmail.com> wrote: > > > If I had to pick one feature that makes git more useful than svn, it > would > > be the ease in creating feature branches. If you want to add a feature, > > you simply create a local branch to implement the feature, implement it, > > and commit it, and create a pull request. If you're using Atlassian's > > Crucible or Stash, it's pretty easy to do a code review of the pull > > request. > > > > Feature branching makes it easy for developers to get their feet wet > with a > > code base. You can try out experiments. Have branches for each > experiment. > > It makes it easier to attract new developers to a project. > > > > From the previous discussion thread, it seems like the main objections > were > > (paraphrasing a bit here): > > > > - I'm not familiar with git. I've got a process that works for me and > I > > don't want to change it. > > - I don't see the value in it. > > - We don't know the impact on the release process. > > > > > > In order to address these concerns, it makes sense to try it out on a > > project. The next question is -- which project. The project needs to be > > central enough that everyone has some skin in the game. It should be a > > project that you have an interest in. If you haven't used git before, > then > > you need to try implementing a feature in that project. The project lead > > should also be someone who's familiar with git, and feels comfortable > with > > answering questions about git. > > > > I think if we can identify a project, and get commitment from everyone > who > > hasn't tried git, to add a small feature, add some comments, or add a > unit > > test, we'll learn enough. The project lead can look at the impact on the > > release process, and report any findings. At least at that point, we'll > > have learned enough from the process to make an informed decision. > > > > > > Regards, > > > > Mark > > > > > > > > On Tue, Sep 9, 2014 at 8:27 AM, Emmanuel Bourg <ebo...@apache.org> > wrote: > > > > > Le 09/09/2014 16:52, Paul Benedict a écrit : > > > > Is there an itch to scratch (need) by moving to git as opposed to > just > > > > continue using svn? > > > > > > I guess the "itch" is simply an increasing preference for Git among the > > > people involved here. I don't think the migration will fix any > important > > > problem. > > > > > > Emmanuel Bourg > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > >
