On Sat, Jan 29, 2011 at 6:08 PM, John Maddock
I think you're looking at it as a purely tool vs tool comparison which doesn't amount to much. Consider then what the workflow a distributed version control system enables and you might see the difference clearer.
Consider a library being worked on by N different people concurrently. Each one can work on exactly the same code locally, making their changes locally. Then say someone pushes their changes to the "canonical" repository. Each person can then pull these changes locally, stabilizing their own local repository, and fixing things until it's stable. You can keep doing this every time without any one of these N people waiting on anybody to "finish".
That's exactly what we do now with SVN.
Something was missing in translation there: making changes, means committing locally. That's not what we do now with SVN. See, when you're using git, committing locally and making changes are equivalent. It's something you don't think about as something different -- as opposed to how you think about it in SVN where "making changes" is not equivalent to "committing". Therefore were you see git users say 'making changes' that really means 'committing changes locally'.
Now then imagine that there's only one person who has push capabilities/rights to that "canonical" repository and that person's called a maintainer.
All the N-1 people then ask this maintainer to pull changes in or merge patches submitted by them. If the maintainer is willing and capable, that's fine and dandy changes get merged. Now consider when maintainer is unwilling or incapable, what happens to the changes these N-1 people make? Simple, they publish their repository somewhere accessible and all the N-2 people can congregate around that repository instead. MIA maintainer out of the way, release managers can choose to pull from someone else's published version of the library. Easy as pie.
OK, if forking is a good thing then I can see how that helps.
Is there any question that forking is a good thing? I thought that was kinda assumed with open source development. ;-)
Question: what's to stop you from right now, building a better and greater version of library X in the sandbox, and then asking the Boost community to consider that the new Trunk and you the new maintainer? Different tool, same process.
Because doing that requires permission to get sandbox access. And because doing that is largely more steps than just clicking a 'fork' button on a web UI on something like github. And also because doing that means that you have to work with a single repository that has potentially other people clobbering it. :)
I still think there are pros and cons though:
* As I see it Git encourages developers to keep their changes local for longer and then merge when stable. That's cool, and I can see some advantages especially for developers wanting to get involved, but I predict more work for maintainers of the canonical repro trying to figure out how to resolve all those conflicts.
What gives the impression that resolving conflicts is hard on git? It's easily one of the easiest things to do with git along with branching. And because branching is so light-weight in git (meaning you don't have to pull the branch everytime you're switching between branches on your local repo) these conflict resolution and feature-development isolation is part of the daily work that comes with software development on Git. And having multiple maintainers maintaining a single "canonical" git repo is the sweetest thing ever. Merging changes from many different sources into a single "master" is actually *fun* as opposed to painful with a centralized VCS.
Obviously with SVN we still get conflicts - for example Paul and I often step on each others toes editing the Math lib docs - but these issues tend to crop up sooner rather than later which at least makes the issue manageable to some level.
See, imagine how that would scale if you added 2 more people working on the same library with SVN. Just updating everytime you need to commit anything is a pain with the potentially huge conflicts you get precisely because you can't commit changes more granularly locally in your repository. Note that there's no notion of a "working copy" because your local repository is what you work on directly. The "pull-merge-push" workflow is so simple with git that it's largely not something you *ever* have to deal with in any special manner. It's just part of everyday development with git. A suggestion would be maybe someone ought to run a workshop or a tutorial IRL on how the git workflow looks like. I think there are tons of videos out there already along with countless books written on the subject already.
* I happen to like the fact that SVN stores things *not on my hard drive*, it means I just don't have to worry about what happens if my laptop goes belly up, gets lost, stolen, dropped, or heaven forbid "coffeed". On the other hand the "instant" commits and version history from a local copy would be nice...
See, git does the same thing if you're using github as a publicly accessible repo. You can duplicate the same to gitorious. You can even put it on sourceforge for good measure. Synchronizing each one is a scriptable manner and is not rocket science. The fact that this is even possible with git is something that gives it much more appeal for disaster recovery. With SVN, if you're working on something locally (not committed yet) and your hard-drive goes belly up, I don't see why it's better than if you were working on git and have local commits and your hard-drive goes belly up. With SVN though the question is what happens when your server gets wiped out, what value is the data on your hard-drive then? How do you reconstitute the history of the project from what you do have with you? With git the risk mitigation options are a lot more accessible and largely trivial. With SVN, not so much. HTH -- Dean Michael Berris about.me/deanberris