From Google Summer of Code Mentor Wiki
[edit] Why Not adopt a DVCS?
* no hooks
* answer: hooks still work with DVCS, but they happen on the controlled servers at push time. People can set up, eg commit hooks in their own clones - supply a script in your project's maintenance tools that installs them
* accountability - ie, who pushed?
* samv says: not really an issue most of the time, because usually the more important question is who wrote it, not who pushed it, and push access can be restricted to just the primary maintainer. you can of course use signed tags etc.
* djc says: Mozilla has written a hook that keeps pushdata in an SQLite database and provides various interfaces to that information
* non-technical contributors (e.g. translators)
* answer: in the simple cases, DVCS is not fundamentally harder than centralized systems, just different
* difficulty of contribution
* answer: make sure your project has instructions for contributing, and that they are tested. Pick a simple subset of possible workflows, and go through it in detail.
* huge history
* come to the session Sunday afternoon about migrations, large repositories will be discussed then
* module & tree layout seems to get more complex every time we migrate
* IDE support can be poor
* git has a CVS-compatible proxy (git-cvsserver). There was a git-svnserver project for GSoC 2007, but it missed out on a slot and no-one proposed it for 2008.
[edit] What's Good?
* git: lightweight branches (compared to CVS)
* git: re-basing
* git: merging
* hg: web interface
* Better attribution for contributors (e.g. for Ohloh)
[edit] What's Bad?
* People working off-line for ages: giganto-merges
* Hard to understand what's happening with so many repositories
* Code reviews can be a problem
* Tools can be bureaucratic
[edit] Conversion and Tools
* Tools seem insufficient for migrating big repositories
* Counterexample: GCC.
* Very long history, large source base.
* After the git developers helped out, the GCC git repository was actually smaller than the checked-out working tree!
* Talk to the development team if your repository is big, they can often make things work much better/faster for you
* Changes to your project's work flow can be intimidating / hard to manage / hard to convince people about
* Communication about what's happening where can get more complex
* Notification scripts exist
* There are public repository hosting organizations
* github
* git.or.cz
* bitbucket
* freehg
* assembla
* savannah.nongnu.org
[edit] Getting Started
* It's scary; what will happen when I press ENTER?
* With DCVS, the effect can almost always be backed out without your mistake touching a repository anybody else can see
* Starting a DCVS that is arranged just like a centralised system is quite possible
