[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PATCH] proposed v3 source format using .git.tar.gz

On Mon, 8 Oct 2007 12:59:52 +0200, Frank Lichtenheld <djpig@debian.org> said: 

> On Sun, Oct 07, 2007 at 10:59:18PM -0500, Manoj Srivastava wrote:
>> On Mon, 8 Oct 2007 02:55:37 +0200, Frank Lichtenheld
>> <djpig@debian.org> said:
>> > Lets not exagerate. At least for git the repository will usually be
>> > smaller or only little larger than the working directory. It will
>> > probably compress worse though.
>> How is this magic done? If I have several dozen feature branches, all
>> feeding back and forth, and have made lots and lots of changes in my
>> sources, how does git preserve all this information without a
>> commensurate increase in size?  This makes the information theory
>> geek in me very very skeptical.

> By already using compression in the repository and by aggressively
> storing data as delta against earlier versions (both for binary and
> textual data).

        Well, arch does this in the repo: base versions and cacherevs
 are tar.gz files, and then it stores deltas from the most recent base
 version or cached revisions (I generally cache every 20th revision).

        In any case, I think the kinds of actions taken by joey's and
 Colin's patches are probably not things that we'll have to do to
 support shipping an arh working directory in the source packagel if we
 have {arch}  and .arch-id dirs in the source, the end user has access
 to the distributed version control system; as soon as they register the
 archive location mentioned in the control file entry.

        I am not sure  how the pritine-tar bit fits in into the picture

Eighty percent of married men cheat in America.  The rest cheat in
Europe. Jackie Mason
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Reply to: