Re: Git's database structure

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

 



On 9/5/07, Andreas Ericsson <ae@xxxxxx> wrote:
> Jon Smirl wrote:
> >
> > The path name field needs to be moved back into the blobs to support
> > alternative indexes. For example I want an index on the Signed-off-by
> > field. I use this index to give me the SHAs for the blobs
> > Signed-off-by a particular person. In the current design I have no way
> > of recovering the path name for these blobs other than a brute force
> > search following every path looking for the right SHA.
> >
>
> Ah, there we go. A use-case at last :)
>
> So now we have a concrete problem that we can formulate thus:
> "How can one create a database listing the relationship between 'signers'
> and blobs?"
>
> So the second question: Do you seriously argue that git should take a
> huge performance loss on its common operations to accommodate a need that
> I suspect very few people have?

Why do you keep jumping to a performance loss? Both schemes will have
an index based on paths. The problem is how those indexes are
constructed, not the existence of the index. Moving the paths into the
blobs in no way prevents you from creating an index on that field.

The problem is that the SHAs have been intertwined with the tree
nodes. This blending has made it impossible to create other indexes on
the blobs.

The path index in the flat scheme will probably look just like tree
nodes do today but these new tree nodes won't be intertwined with the
SHAs.


>
> --
> Andreas Ericsson                   andreas.ericsson@xxxxxx
> OP5 AB                             www.op5.se
> Tel: +46 8-230225                  Fax: +46 8-230231
>


-- 
Jon Smirl
jonsmirl@xxxxxxxxx
-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux