<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
</div>I don't think you'll be able to make it such that the file in a 2a<br>
repository is a hardlink to the file in the working tree. Ultimately<br>
there is quite a bit of risk in that. Accidental modification of the<br>
working tree copy, and suddenly your archive is corrupted for everyone,<br>
and you don't have another copy to easily restore from. </blockquote><div><br></div><div>true. my loose object plan involves ensuring that objects going into the store are made read-only (and chown'd to a "repouser" using a simple setuid'd program) so that hardlinks generated from them are not editable. if i were to use 'checkout --hardlink' i'd most likely use a similar approach to ensure that various users don't accidentally edit each other's files across working trees.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
With 'bzr co --lightweight' and '--hardlink', you can easily get to the<br>
point where there is 1 copy on the centralized repository, and all<br>
working trees have hardlinked data.<br></blockquote><div><br></div><div>this could be a good compromise solution, but currently it seems to be missing a critical component: "bzr update --hardlink". "checkout --hardlink" is great to get started, but its benefits disappear after bzr stops trying to use hardlinks for new updates. ideally, when updating with "--hardlink" each repo would have a list of shared repo paths that it would first search (recursively?) to generate hardlinks, before defaulting to the normal behavior if nothing suitable is found. this search pattern would also be useful for "checkout --hardlink" which currently only looks to the source repo's working tree. for instance, if the -r flag is specified on checkout to get some older revision, the working tree of the source repo might not have any revisions to hard link from, but other clones (sorry for hg/git terminology!) very well might.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
'bzr co --lightweight' isn't as fast as it could be, but it is decent,<br>
and IMO would be much more worth your time than a new storage format.</blockquote><div> </div><div>agreed. i gave --lightweight a test drive and it works like mercurial's "shared" repo, which i like conceptually more than git's shared repos. </div>
<div><br></div><div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
I'll note, though, that the git 'loose blobs' are not simply file <span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">content. IIRC they have a 'blob ####' header (# is the length, IIRC), </span><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">and then the whole content is DEFLATE compressed. </span><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">So even that doesn't fit his goal of having one copy of the text between </span><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">the repository and the working tree.</span></blockquote>
</div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><br></span></div><div>true. as a proof of concept, i modified the git C code to separate the header and leave the blob uncompressed. doing this to the dulwich python code would be trivial.</div>
<div><br></div><div>i'm going to start playing with the patch that John sent to disable delta compression. btw, a similar patch can be made to mercurial to boost performance with large files, but unlike bzr, mercurial does not have a handy pack command to later recompress. </div>
<div><br></div><div>one more question about packs: is it possible to *quickly* and *easily* punch/prune/obliterate a file revision from the repo? git does this well, mercurial does not. i checked `bzr help pack` and it did not show any options for this, but it also does not show "<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">--clean-obsolete-packs" (on version 2.2b1). what's up with that?</span></div>
<div><br></div><div>thanks again for all the great responses. this definitely the most informative mailing list that i've spammed lately :)</div><div><br></div><div>-chad</div><div><br></div><div><br></div></div>