DVCS vs. Subversion brittleness (was Re: Moving to D)

[Bruno Medeiros]

On 01/02/2011 23:07, Walter Bright wrote:
> Bruno Medeiros wrote:
>> A more serious issue that I learned (or rather forgotten about before
>> and remembered now) is the whole DVCSes keep the whole repository
>> history locally aspect, which has important ramifications. If the
>> repository is big, although disk space may not be much of an issue,
>
> I still find myself worrying about disk usage, despite being able to get
> a 2T drive these days for under a hundred bucks. Old patterns of thought
> die hard.

Well, like I said, my concern about size is not so much disk space, but 
the time to make local copies of the repository, or cloning it from the 
internet (and the associated transfer times), both of which are not 
neglectable yet.
My project at work could easily have gone to 1Gb of repo size if in the 
last year or so it has been stored on a DVCS! :S

I hope this gets addressed at some point. But I fear that the main 
developers of both Git and Mercurial may be too "biased" to experience 
projects which are typically somewhat small in size, in terms of bytes 
(projects that consist almost entirely of source code).
For example, in UI applications it would be common to store binary data 
(images, sounds, etc.) in the source control. The other case is what I 
mentioned before, wanting to store dependencies together with the 
project (in my case including the javadoc and source code of the 
dependencies - and there's very good reasons to want to do that).

In this analysis:
http://code.google.com/p/support/wiki/DVCSAnalysis
they said that Git has some functionality to address this issue:
"Client Storage Management. Both Mercurial and Git allow users to 
selectively pull branches from other repositories. This provides an 
upfront mechanism for narrowing the amount of history stored locally. In 
addition, Git allows previously pulled branches to be discarded. Git 
also allows old revision data to be pruned from the local repository 
(while still keeping recent revision data on those branches). With 
Mercurial, if a branch is in the local repository, then all of its 
revisions (back to the very initial commit) must also be present, and 
there is no way to prune branches other than by creating a new 
repository and selectively pulling branches into it. There has been some 
work addressing this in Mercurial, but nothing official yet."

However I couldn't find more info about this, and other articles and 
comments about Git seem to omit or contradict this... :S
Can Git really have an usable but incomplete local clone?

-- 
Bruno Medeiros - Software Engineer