On Tue, Jan 27, 2009 at 10:49 AM, Daniel Ruoso <dan...@ruoso.com> wrote:
> Em Ter, 2009-01-27 às 10:18 -0600, Patrick R. Michaud escreveu: > > Well, we're now at the point where it's time to move the > > Rakudo repository, and thus we need a decision on continuing > > to use svn for the repository or switching to git. > > I think it primarily depends on how you're planning to manage the > development. If you intend to keep a centralized management of the > repository, keeping track of all the committers and branches, svn is > probably the best choice, and people who like git can always use > git-svn, additionally one could keep a git repository hosted somewhere > that was frequently sync-ed with the svn repo. > > On the other hand, if you'd like to make it have a more loose > management, you should probably use git, which would allow branches to > be hosted anywhere developers want and you would only manage the > "official" branch of the code and the release branches as well. > > As a more incisive comment, I personally experienced bad merge behavior > in svn several times, while git has positively surprised me several > times.. I don't know ... I don't think it much matters how development is to be "managed". Git can be managed identically to subversion, so there's no difference there unless there's something that you want from git that svn doesn't provide. And for me, that's the advantage of git--you get things that you don't have or don't easily have with subversion. Here's a rough list in no particular order: - sane merges (you don't have to remember to annotate commits with merge info nor do you have to destroy your branches once you've reintegrated them with main development) - private branches (I think this one speaks for itself :) - git bisect (relatively easily find commits that broke something) - git supports multiple workflows - git lets you select just the changes you want to commit (say you've accidentally comingled two feature changes, but you want to commit them separately) - git lets you collapse or explode local commits before pushing them upstream (maybe it took you 5 commits to fully implement a feature, you can make that a single feature commit upstream if you desire) - git format-patch/git send-email/git am (if you're not a commiter, you can easily generate patches, send them, and developers can easily apply them. BTW, this triumvirate can be used independent of each other) - git is really fast (the larger the repo, the more you notice this) - github - git is more efficient WRT disk usage. Okay ... I really wasn't trying to proselytize git, but these are the features that attract me to git and why I use it (particularly those first few). There are also a few intangibles that make git a good fit for me. It seems to have the perl-nature of TMTOWTDI and the idea of "many histories" (as contrasted with svn's linear history), seems to be more the way the world really works. okay, I'll shut up now except to say this: I prefer git :-) -Scott -- Jonathan Scott Duff perlpi...@gmail.com
