please check out weave-format branch
martinpool at gmail.com
Fri Sep 23 07:36:14 BST 2005
On 23/09/05, John Arbash Meinel <john at arbash-meinel.com> wrote:
Thanks for all the good questions.
> I'm looking through the new revision and inventory XML, (though it is a
> little tricky to parse through the weaves, at least they are text :).
> Is there a simple command to say "give me this version of the
> inventory.weave file"?
If you run bzrlib/weave.py as a script it has several useful options,
including extracting a particular text, showing the table of contents
for a weave, and checking the self-consistency of that particular
weave in isolation. I'll turn them into bzr subcommands. We should
also have perhaps 'bzr inventory --raw'.
> 1) inventories now have a "text_version" and a "name_version". I assume
> you are storing the last changed version for the name and the last
> changed version for the text. Is this really necessary? Are you trying
> to make it so that you don't need to add a new entry to the weave file
> if only the name changes? Is it expensive to add a new version with
> identical contents? Not a big deal, though. I'm guessing your method is
> just fine.
No, it's fairly cheap to add a new identical version. In fact it
could be a lot cheaper if we know ahead of time they're identical, as
we'd just add an entry to the weave table of contents.
The idea of storing a name version is so that we can use it in merging
tree shape, by seeing if either or both names have been changed since
the common ancestors. Keeping that separate from the text version
lets us identify that a file has been renamed on only one side, though
the text has been edited on both. (There are other ways you can do
it.) It might turn out that having just a single version is enough.
> 2) Is it really that difficult to have bzr.newformat support the
> oldformat? All you have to do is detect it from .bzr/branch-format, and
> then create the old stores, etc. (I'm not sure what else you changed in
> the code, though.) It looks like you are doing the check, but rely on
> "relax_version_check" which is probably only set by the upgrade code.
> >From what I've seen, the new code might depend on things like the
> ancestry file, so it might be required.
The commit and fetch code is considerably changed, so supporting r/w
access to old branches would probably require having both copies of it
around. It could certainly be done though at this stage I don't know
if it's really needed. (I just have the new one on my path as 'bzr5'
so i can run both).
We could have readonly access to old branches if we want.
I wouldn't want to have too many more transitions like this, so we
should add a storage abstraction.
More information about the bazaar