Version Control Software

[Chris Angelico]

On Sun, Jun 16, 2013 at 1:55 PM, rusi <rustompmody at gmail.com> wrote:
> On Jun 16, 4:14 am, Chris Angelico <ros... at gmail.com> wrote:
>> On Sun, Jun 16, 2013 at 12:16 AM, Roy Smith <r... at panix.com> wrote:
>> > The advantage of DVCS is that everybody has a full copy of the repo.
>> > The disadvantage of the DVCS is that every MUST have a full copy of the
>> > repo.  When a repo gets big, you may not want to pull all of that data
>> > just to get the subtree you need.
>>
>> Yeah, and depending on size, that can be a major problem. While git
>> _will_ let you make a shallow clone, it won't let you push from that,
>> so it's good only for read-only repositories (we use git to manage
>> software deployments at work - shallow clones are perfect) or for
>> working with patch files.
>>
>> Hmm. ~/cpython/.hg is 200MB+, but ~/pike/.git is only 86MB. Does
>> Mercurial compress its content? A tar.gz of each comes down, but only
>> to ~170MB and ~75MB respectively, so I'm guessing the bulk of it is
>> already compressed. But 200MB for cpython seems like a lot.
>
> [I am assuming that you have run  "git gc --aggressive" before giving
> those figures]

They're both clones done for the purpose of building, so I hadn't run
any sort of garbage collect.

> Your data would tell me that python is about twice as large a project
> as pike in terms of number of commits. Isn't this a natural conclusion?

I didn't think there would be that much difference, tbh. Mainly, I'm
just seeing cpython as not being 200MB of history, or so I'd thought.
Pike has ~30K commits (based on 'git log --oneline|wc -l'); CPython
has roughly 80K (based on 'hg log|grep changeset|wc -l' - there's
likely an easier way but I don't know Mercurial). So yeah, okay, it's
been doing more. But I still don't see 200MB in that. Seems a lot of
content.

ChrisA