On 20 Dec 2013, at 16:11, Markus Hitter <[email protected]> wrote: > Am 20.12.2013 16:05, schrieb David Chisnall: >> - svn or git views of the repo, so developers can use either > > That's possible with pure SVN repos, too. git-svn will check out a SVN > repo just fine and you can work with it as if it were a Git repo.
If you want to use git-svn yourself, yes. However, you then lose all of the integration with things like GitHub, where forking the repo is a one-click operation. This is a big difference, because one of the attractive things about something like GitHub is that you get the distributed nature of git WITHOUT the large number of forks hidden on people's laptops. Anything forked on GitHub is publicly visible (unless you pay GitHub money for it to be private). You can then do a private clone and not share things, but the easiest way of working is to have everything public, which eliminates the biggest downside of git (i.e. interesting work ends up on dead laptops without backups). Additionally, the GitHub svn stuff correctly handles branches and so on, so people who want to have an svn workflow get to use svn as if there were not git involved, people who want to have a git workflow get to use git as if there were no svn involved. For patches, not being able to attack them is annoying, but you can still post diffs inline. That's fine for small patches, for larger ones it's generally more convenient to have them in small chunks, and having them broken up into smaller commits, and the GitHub workflow works very well for this as you can attach multiple revisions to a bug report / pull request. The nicest thing to do is branch your fork, rebase the branch on upstream, and then send the resulting commits as the pull request. Of course, for GNUstep the biggest blocker is requiring copyright assignment... David _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
