On Fri, 6 Nov 2009, Avery Pennarun wrote:
This
lousy performance isn't the case in git (except in Windows). Are you
using Windows, by chance?
yes. I did not yet noticed any performance problems with Git on windows, except
a sync/download time (for android, mostly)
Basically, performance is linear with the number of files in your
repo. If you can check out just a "slice" of your repo (say 10% of
the whole), you'll have faster performance (eg. 10x) from any VCS.
git on Linux is so fast that this isn't very necessary most of the
time. But git on Windows isn't really any faster than other VCSes on
Windows, so the time-per-file is much greater, and thus the penalty
for huge repositories is much worse. Doing things like switching
branches, which is near-instantaneous on Linux even with tens of
thousands of files, really crawls on Windows.
but is that scale based on the number of files you are tracking, or the
number of revisions that exist in the repository.
i.e. 10,000 files in the source code with 10 revisions each vs 1,000
files with 100 revisions each.
my understanding of git is that it's the number of files, with very little
impact due to having lots of revisions. so eliminating 90 revisions of
each file would not significantly speed up git in the second case.
going back to the initial poster's comments. if the android repo is 1G,
eliminating the history will probably have significantly less impact than
you expect it to. for source code the compression factor that git is able
to get is spectacular. I've seen several cases posted with large projects
where the full repo with ALL history is <2x the size of a tar.gz of the
latest release.
David Lang
So I can see an argument that Windows users would want arbitrary
"slices" much more often than Linux+git users, but I think this is
largely due to performance, not because people really *want* to be
stuck with a restricted view of the repo.
Have fun,
Avery
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html