All of lore.kernel.org
 help / color / mirror / Atom feed
From: david@lang.hm
To: Avery Pennarun <apenwarr@gmail.com>
Cc: Dmitry Smirnov <divis1969@gmail.com>, git@vger.kernel.org
Subject: Re: Git drawbacks?
Date: Fri, 6 Nov 2009 10:57:58 -0800 (PST)	[thread overview]
Message-ID: <alpine.DEB.2.00.0911061051540.3216@asgard.lang.hm> (raw)
In-Reply-To: <32541b130911060951q3358ce9ahe28fb0cf902853f2@mail.gmail.com>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2206 bytes --]

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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

  reply	other threads:[~2009-11-06 18:58 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-06 16:17 Git drawbacks? Dmitry Smirnov
2009-11-06 16:49 ` Avery Pennarun
2009-11-06 17:35   ` Dmitry Smirnov
2009-11-06 17:41     ` Jacob Helwig
2009-11-06 17:51     ` Avery Pennarun
2009-11-06 18:57       ` david [this message]
2009-11-09  7:53         ` Dmitry Smirnov
2009-11-09 14:34           ` Jacob Helwig
2009-11-09 15:59             ` Dmitry Smirnov
2009-11-09 16:21               ` Jacob Helwig
2009-11-09 15:48           ` Dmitry Potapov
2009-11-09 16:11             ` Dmitry Smirnov
2009-11-09 18:34               ` Dmitry Potapov
2009-11-10  8:31                 ` Dmitry Smirnov
2009-11-10 13:45                   ` Dmitry Potapov
2009-11-10 14:14                     ` Dmitry Smirnov
2009-11-10 16:15                       ` Paolo Bonzini
2009-11-09 18:47               ` B Smith-Mannschott
2009-11-09 21:06                 ` Dmitry Potapov
2009-11-10  8:51                   ` Dmitry Smirnov
2009-11-10 14:04                     ` Dmitry Potapov
2009-11-10 14:54                       ` Dmitry Smirnov
2009-11-10 16:20                         ` Paolo Bonzini
2009-11-10 23:43                         ` Dmitry Potapov
2009-11-10  9:08                 ` Dmitry Smirnov
2009-11-09  7:22       ` Dmitry Smirnov
2009-11-11 10:21 ` Dmitry Smirnov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.00.0911061051540.3216@asgard.lang.hm \
    --to=david@lang.hm \
    --cc=apenwarr@gmail.com \
    --cc=divis1969@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.