5 ms·

The main issue we faced wasn't really branching, but the merging that needed to happen after that. It was a real pain. Here is a detailed explanation on why it

• millstone 13y ago
  Were you using an old version of svn? Merging has gotten a lot better starting with 1.5. I don't agree with most of the points in that post. Let's go through them: 1. "It doesn't have merge tracking." That was true at one point: manual merge tracking was indeed a miserable, error-prone experience. But automatic merge tracking was introduced five years ago, so this criticism is no longer relevant. 2. "You have to see everyone's experimental branches." This is not so: you can use any directory hierarchy you like, so you can cordon off experimental branches any way you want. A common workflow is to have a directory per engineer, in which case you don't see their private branches until you go poking around in their directory. And storing private branches on the server (where they get backed up) can only be a good thing. 3. "git better handles sending patches around through uniquely identifiable revisions." Here "uniquely identifiable" means across separate repositories. This is only relevant in a truly distributed system, where there really is no central server containing the truth. For the truly distributed case, git is clearly to be preferred. But most teams really do use a central server. Like github! Overall, I think the answer is: it doesn't matter much. git and svn in their modern forms are both very powerful and capable tools. There's a few cases where one excels the other: git is better if you have multiple repositories, while svn is better if you have a large quantity of images or binary files. But for most teams, either tool is more than adequate, and it comes down to experience or personal taste.
  • mataug 13y ago
    Okay how about this, There is not a Central Server UI for SVN that comes close to Github ! Rebase is very difficult to out-right impossible.