[BUG] spurious tree root changes in workingtree2 and 3

[Robert Collins]

On Thu, 2007-08-23 at 21:48 -0400, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Robert Collins wrote:
> > I realise this has probably been done to death somewhat; but what do you
> > think of exposing 'None' as the revision in this case? It would let me
> > detect when it should not be included in the commit candidates list.
> 
> I don't know why you would want to exclude it.  That decision should be
> made by the CommitBuilder.

Well the CommitBuilder is generated by the repository; so is the content
of the RevisionTree. So they are coupled already. My iterator is
encoding the logic used to exclude inventory entries from being given to
the CommitBuilder at all - we're working towards the delta based commit
so that a commit of a few files on a large tree does not process O(tree
entries) data. If root has to be always included, I guess thats ok, but
it seems wrong to me when we can filter it out earlier.

> I don't want the result of revision_tree() to differ between knit1 and
> knit3 repos.

They do already though; in a knit3 repo the .revision does not change
unless the root has actually been modified. Or are you saying that the
assigned last_modified of a converted knit1 inventory is its revision
id ?

> > As far as the changes to recorded transitive alterations in inventories,
> > its not clear to me that that will affect the last_modified flag.
> 
> If it affects the InventoryEntry, then I believe it must affect the
> last_modified flag.

So the question to me resolves around whether 'when was a child last
modified' is part of the inventory entry or not. You can make it live
there, or you can say that you can query for that, and some formats will
have an immediate answer, others will have to do more work.

> But I was talking about it affecting knit records, not the last_modified
> flag.  I am not one of the people who championed the use of knits to
> record when inventory entries had changed.  But that has become part of
> our model, and it is logical to suppose that would be extended to adding
> knit records when the contents of directories have changed.

Much of my work at the moment is centred around breaking that coupling
between metadata and knit-graphs.

> > It may
> > well just add another field, or be an emergent aspect of the storage.
> 
> Well, no one's said anything about it.
> 
> I just think the tone of your initial email was a bit extreme.  There's
> already plenty of useless knit records in our repositories-- uncommitted
> revisions, unreferenced file texts, and texts that are unchanged from
> the previous version.

Thats a fair call, sorry.

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070824/a289f50e/attachment.pgp