Distributed bug tracking

> Still nobody else can see the 
> code, so there is no peer review yet

Linus amongst others would argue that is a major benefit of DVCS.  Sometimes a programmer will
have an idea which they want to be able to play with without telling the whole world about it
- which is what happens if you create a branch in SVN. 

Good reasons for keeping code private, at least initially:

* The idea may turn out to be impractical or stupid.  In that case you won't upset anyone
because nobody else knew about it and you won't leave 'dead-end' branches lying around in the
main repository.
* People may appreciate the ability to work on something for a while without subjecting it to
criticism until they are ready.
* There may be competition within the project or in competing projects. 
* The code might not be suitable for inclusion in the main code base - it might be a
modification of the software to meet the needs of a specific company for example.  

In addition to secrecy, there is also the case where developers want a branch to handle their
specific needs which are not useful to anyone else.


> Doesn't this encourage big commits later on to the official/main 
> tree, which are too big to understand easily ?

Not necessarily - because users can easily browse the history of the merged branch and see the
individual changes which went into the final merge.    

One big practical advantage of course is speed.  Branching, merging and viewing history can be
very slow in SVN if the server is under load.  In git/bzr etc. creating a new branch is
instant and checking it out normally takes only a few seconds.  Merging is also trivial and
again takes only a few moments in most cases and it isn't affected by what is going on at the
remote end.  Being able to get a near-instant log is also very nice.  Having to wait two
minutes for "svn log" to fetch the history of a particular file is pretty frustrating.