sftp oddities

[Johan Rydberg]

Aaron Bentley <aaron.bentley at utoronto.ca> writes:

>> As I see it, there are two solutions to this, both simple: Either the
>> inventory and other control files are put under /branch/, or we tell
>> the end-users that if they have unrelated branches in the same
>> repository they got no one but them selves to blame if performance
>> is degrading.
>
> I don't think either solution is very nice.  I think we'd rather
> take advantage of all shared data for related branches, and
> differentiate between related and unrelated branches.  What we
> discussed at UBZ was to assign an inventory ID to the tree root, and
> then have a separate inventory weave for each tree root

Yes. 

This will become less of an problem if we split the inventory into
several files, on directory basis.

> I don't think we discussed using that differentiation for revisions,
> because at the time, revisions were always stored as flat files.
> Perhaps we're merely using the tree root ID as a project ID, and
> that could become more pervasive.

They could also be stored in a versioned file named after the project
ID.

>> This is more of an issue for knits, where there are more shared
>> control files than just the inventory.
>
> Could you elaborate?

All revisions are stored in a versioned file in the control store (ie,
directly under .bzr) alongside a file called "changes" which holds
information about what changes each revision introduced.  In simple
terms, it is a serialized form of a TreeDelta object.  This enables
the fetcher to figure out what file versions to fetch without
comparing revision inventories.  Which cut the branch time of bzr.dev
from ~25 minutes down to two.

As I said, "revision changes" information is right now stored in a
separate file.  This information could of course be put in the
revision file along side the revision information, but I wanted to
keep the current XML format of revision information for now.
I might migrate to rio-based serialization sometime in the future.

> Aaron

~j