re-added support for ghosts in newformat

[John A Meinel]

Robert Collins wrote:
> On Tue, 2005-10-04 at 17:36 -0500, John A Meinel wrote:
>
>
>
>>Actually, it is much worse than a simple probe.
>>
>>The problem is that in my code, I was able to use "has_multi" which
>>should allow a pipelined check, if you requested 50 files, I could check
>>for their existence in a single command.
>
>
> Well, there are two cases I can see here. With a smart server, you'd be
> asking for the file ids, not the disk names, so - no problem. Without a
> smart server, you would have to issue at most 2 requests:
> one for the 50
> one for those of the 50 that the first did not find.
>
> I'm curious what mechanism you are using to [efficiently] probe for 50
> objects remotely though.

Well, right now I'm not doing any probing :)

It was more that I am able to pass the probe down to a lower level
(Transport) which can be made to be efficient.

If you are going to bring async all the way up the chain, then it
doesn't matter.

My original goal with Transport is that the *_multi commands could
switch into async mode to go extra fast with pipelining, but everything
else would be sync.

The idea was that whenever you knew that you would want 50 files, you
could tell the async code that, and it would let you know when it was done.

Since you are planning on making "bzrlib" be an event driven library a
lot of things change. You can make a request for a couple of files, and
when 1 comes back you might realize that you need another 5.

But honestly, the advantage of my *_multi functions are greatly
diminished by the fact that we are switching to the .weave format. Now,
we are generally going to download a few big files, rather than many
(oversized) ones.

If we had the revfile format, or an indexed weave format, I have
"get_partial_multi" which, in theory, could support grabbing a bunch of
chunks.

*_multi is probably completely obsoleted by using async throughout. They
really were only there to hide the async stuff.

>
>
>>Do you feel that CompressedText has a future? I thought we only needed
>>to support it to allow for "bzr upgrade".
>
>
> Well, I've been turning on compression for revisions in my baz2bzr
> branches, because I have a lot of revisions.

Do you actually save any real disk space (as reported by say df, not du).

Wouldn't hardlinking save you a lot more?

>
> Rob
>

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051004/59b1011a/attachment.pgp