[PATCH] fixes for log -v

John A Meinel john at arbash-meinel.com
Fri Jul 15 17:26:53 BST 2005


Aaron Bentley wrote:
> The recent patches that give an ID to the root directory messed up log
> -v, because they failed to initialize EmptyTree with a root ID in every
> case.
>
> Even my fixed version of these patches is somewhat broken because they
> assume the root ID of the working tree is the root ID of the first
> revision.  But of course, the whole point of these patches is to allow
> the root ID to vary.

Is that actually the point? For me, the point was just so that you can
merge a root id into another tree at some non-root location.

>
> In fact, I am not sure this is the correct way to ensure that root has a
> mutable ID.  My vision of the way we handle this is that all revisions
> are descendants of the null revision.  The null revision's working tree
> is EmptyTree.  Since there's only one null revision, we cannot have
> different kinds of empty tree.  Either EmptyTree's root is not
> versioned, or its root ID is the same for every tree, but either way,
> its contents must be consistent.

I kind of like this. I think having EmptyTree have a null root is nice.
Just we need to have merge be aware of what to report.
Because, actually if you have a freshly initialized tree, it probably
should report that the root id was added. Since you need some way to
re-generate it later.

It also means that changesets don't have to report an explicit
tree-root, as it can either show up as an add/modify or it could be
special case (if tree_root_id != expected_root_id): print '# tree root
id: %s' % tree_root_id

By the way, spaces, tabs, etc are not valid characters in revision_ids
or file_ids. I'm not sure about text ids, but for the other two the
regex is "[\w.]" (for file-ids there is a re.sub('[^\w.]', '') so remove
everything that is not a word or '.'. That allows underscore, but
removes dashes.
I'm not sure what '\w' matches for Unicode, but I don't know if it
really matters (python doesn't seem to handle unicode filenames on
windows or cygwin, but it seems to do okay on Mac, and I assume Linux.)
In my testing, '\w.' doesn't match any arabic characters, but I don't
know about less exotic Latin-1/european characters.

>
> It's not very helpful for the root id to always be initialized to the
> same value, even if you can later change it, because that means it's
> awkward to create a supertree from several projects, in which each
> origninal root is a subdirectory in the supertree.

My thinking was that each tree would get a unique id at "bzr init" time,
and that would be constant for the life of that tree and all of it's
branches. But if you allow for changing that id, I don't think it is a
big stretch.

>
> I think the right way would be to say the empty tree's root is not
> versioned, and to add an ID (but *not* the directory) for the root
> revision.  So directory creation and deletion for the current tree root
> would be handled as no-ops.

Sure.

>
> If this goes on, we're gonna need to be able to handle root directory
> *moves* at some point.  The simplest way I can think of would involve
> creating a temp directory that is a sibling to the tree root, moving the
> tree root into it, and moving the sibling in place of the tree root.
> Unfortunately, this would require write access to the parent of the tree
> root, which is something we haven't required until now.

I'm not really seeing why this is required. Are you thinking that you
want to take a sub-directory and make it the tree-root (and possibly
move the old tree root into a sub-directory)? It seems rather
complicated to handle "move this root out of the way, and move this one
in place" by doing explicit directory moves.
>
> We could also simulate moving the tree root by moving all its contents,
> but I worry that this could lead to inconsistencies.

I'm not sure what inconsistency this would be. It seems to me one of the
only reasons for directories to have an id, is so that you have a place
for children to call their parent.

Speaking of this, we need to figure out a way to do the "no-op merge" in
arch this was sync-tree. The issue is that if I make a branch, and move
things around as a sub-project, I want to make sure that I can pull that
patch back into the parent, without actually applying it.
>
> Aaron

Thanks for creating the cleanup branch. I'm sorry my changes weren't
tested more thoroughly before merging. I can also claim that my
tree-root code was done a long time ago (I think it was around revno 600
or so, and now we are > 900).

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/20050715/2ca7f562/attachment.pgp 


More information about the bazaar mailing list