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
