On Thu, Mar 12, 2009 at 10:27 AM, Gregory Maxwell <[email protected]> wrote: > On Wed, Mar 11, 2009 at 8:34 PM, Daniel Cheng <[email protected]> > wrote: >> You means insert those object as CHK@ ...? >> >> Then you have another set of problems: >> 1) Some kind of pointer (be it SSK@, KSK@ or metadata in some file) >> must exist. The egit-freenet client *have* to know the hash for your >> c...@.. >> If the pointer (let's assume it is a SSK@) fall out from the network, >> we need the private key owner to recover. >> -- this is no better then the scheme i proposed. >> 2) objects are always identical, but packs are not. >> To generate exactly the same CHK@, we have to either keep all >> object loose (lots of very small files, too slow), or come up with >> a packing order / scheme (just plain impossible) > > I had assumed there would be a SSK referenced manifest which list the > objects in the repo by hash along with an identifier for the CHK of > the pack that contains them. If the clients save this information and
That is, keep all objects loose? If you means ordinary SSK manifest -- it does not support so many files in a single directory. > don't purge any of the original objects, any of them should be able to > reconstruct the CHK packs and reinsert the complete repo if it happens > to fall out of the network. <side-talk> Just to mess up the matter even more: All object files are compressing using deflect algorithm, different zlib version is known to generate different compressed bytes. Unless, of course, if you want to keep them decompressed.... (same applies to the compression code in freenet, not to mention the plans to change these in 0.9) </side-talk> > Also, reinserting just the CHK packs does have a big advantage: When > something is actively developed people will often pull the SSK index <fact-check> If the repository was seeded with jSite, the current code always pull the original SSK -- to get the .git/HEAD file. </fact-check> > and any new CHK packs, but old packs may fall out of the network > because no one requests them anymore, yet a new user needs them for > their initial pull. Plans is to have this merged upstream. Code that is too inventive are not welcomed. I have investigated the possibility to insert loose objects, redirects, etc.. yet cannot found a way to do this without changing (or duplicating) too much code in upstream. However, I have just spend one weekend in egit/jgit code... I may have missed something. If you know there are any ways to do this, patches are always welcome. _______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
