From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
To: elton sky <eltonsky9404@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: GSoC - Designing a faster index format
Date: Wed, 4 Apr 2012 19:20:47 +0700 [thread overview]
Message-ID: <CACsJy8A+0GxePYPSJh9g_N83QXY8cf8HHGT65M_eNGBeAs-5uQ@mail.gmail.com> (raw)
In-Reply-To: <CAKTdtZm4JFkWOq7D=tHC-t8C5yd=AG6MEkKD46z5D7fCRDEfZQ@mail.gmail.com>
On Wed, Apr 4, 2012 at 3:26 PM, elton sky <eltonsky9404@gmail.com> wrote:
> I am not sure how the trailer works.
> I assume there can be multiple trailers, each update will generate a
> new one. Every trailer will point to the root tree (i.e. all trailers
> point to the same block?). So if there are some changes to root, like
> rename, trailers all point to the latest root block?
Each trailer points to the whole new tree. Because trees are
immutable, changing in a tree meangs creating a new one and will also
make a new parent tree (to point to the updated tree because old
parent will always point to old tree). This eventually leads to root
tree change, recorded by the trailer.
> Is the index looks like :
> | HEADER | TREE BLOCKS | TRAILER | TREE BLOCKS | TRAILER | TREE
> BLOCKS | TRAILER | ...
>
> Blocks and trailers are interleaved. The index starts from a few
> blocks (git add file1 file2 file3 ..) and expands as it goes. If file1
> is updated, the tree block containing file1 is updated and appended.
> (At this point, 2 versions of tree blocks containing file is in index
> ?) How do you organize these 2 block in a tree ?
I leave them where they are. They will be indirectly referenced by two
different roots. At that point we have to new full trees, sharing many
subtrees except the one that contains file1 and its ancestors. This
makes it possible to access an old index version by traversing from an
older trailer. Heavy "add -p" users may like this.
> Appended blocks are also a tree or just a list. If it's a list, it
> needs O(n) read time. If it's like a sub tree, I assume it's small,
> because I guess there won't be many changes each time. If it's too
> small then lgn -> n, and in total read time -> n.
It's trees all the way down. I'm not sure why read time is related
here. You read it by traversing from root tree to leaves, no matter
old or new root. Appended trees may push trees farther away and
increase seek time. Other than that, I don't see significant read
performance degradation (really crowded trees may degrade a little bit
because we need to read trees in addition to leaves, but I don't think
it's a big problem).
--
Duy
next prev parent reply other threads:[~2012-04-04 12:21 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-20 23:10 GSoC - Designing a faster index format elton sky
2012-03-21 1:18 ` Nguyen Thai Ngoc Duy
2012-03-21 11:25 ` Thomas Rast
2012-03-21 12:01 ` elton sky
2012-03-22 20:32 ` elton sky
2012-03-23 0:46 ` Jakub Narebski
2012-03-23 1:30 ` Nguyen Thai Ngoc Duy
2012-03-23 10:27 ` elton sky
2012-03-23 11:24 ` Nguyen Thai Ngoc Duy
[not found] ` <CAKTdtZmLOzAgG0uCDcVr+O41XPX-XnoVZjsZWPN-BLjq2oG-7A@mail.gmail.com>
2012-03-24 8:58 ` Nguyen Thai Ngoc Duy
[not found] ` <CAKTdtZkpjVaBSkcieojKj+V7WztT3UDzjGfXyghY=S8mq+X9zw@mail.gmail.com>
[not found] ` <CACsJy8D85thmK_5jLC7MxJtsitLr=zphKiw2miwPu7Exf7ty=Q@mail.gmail.com>
2012-03-26 12:36 ` elton sky
2012-03-26 12:41 ` elton sky
2012-03-26 14:28 ` Thomas Rast
2012-03-26 15:25 ` Nguyen Thai Ngoc Duy
2012-03-26 16:08 ` Shawn Pearce
2012-03-27 2:49 ` elton sky
2012-03-27 3:34 ` David Barr
2012-03-27 6:33 ` Nguyen Thai Ngoc Duy
2012-03-29 9:45 ` Jeff King
2012-03-27 6:31 ` Nguyen Thai Ngoc Duy
2012-03-26 16:19 ` Nguyen Thai Ngoc Duy
2012-03-27 3:20 ` elton sky
2012-03-27 6:43 ` Nguyen Thai Ngoc Duy
2012-04-02 11:50 ` elton sky
2012-04-02 12:31 ` Nguyen Thai Ngoc Duy
2012-04-02 14:27 ` Shawn Pearce
2012-04-02 15:12 ` Nguyen Thai Ngoc Duy
2012-04-04 8:26 ` elton sky
2012-04-04 12:20 ` Nguyen Thai Ngoc Duy [this message]
2012-04-04 16:22 ` elton sky
2012-04-06 3:13 ` elton sky
2012-04-06 3:15 ` elton sky
2012-04-07 8:29 ` elton sky
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=CACsJy8A+0GxePYPSJh9g_N83QXY8cf8HHGT65M_eNGBeAs-5uQ@mail.gmail.com \
--to=pclouds@gmail.com \
--cc=eltonsky9404@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).