[RFC] dirstate and deletes

John Arbash Meinel john at arbash-meinel.com
Tue Sep 12 15:50:40 BST 2006


Aaron Bentley wrote:
> John Arbash Meinel wrote:

...

>>> The issue is you still need a place to store the [parent info] even
>>> though the file has been removed. Because when you go to commit, you
>>> want to find that it isn't there, but it used to be.
> 
> So this is the 'rm foo' case.  Dirstate is intended to be an accurate
> representation of the filesystem, so that I can query it about whether a
> path exists or not?

Actually, I think this is for the 'bzr rm foo' step. Because as you
mentioned, there isn't much to change for a plain 'rm foo'. Especially
since:

'rm foo'; bzr status; 'touch foo'; bzr status

Might show the file as missing for a while, but in the end the file will
only show as modified.


> 
> It seems like dirstate is functioning as both the live inventory and the
> basis inventory, no?  So I guess the representation of unversioned files
> makes sense.

It is functioning as live inventory, basis inventories, and hash cache.

> 
>>> I'm okay with that... I wonder, though, if it would be better to allow
>>> for multiple entries next to each other.
>>>
>>> But dirstate is really designed to be optimized for the: "I have this
>>> file/dir/symlink at this specific path, what is its state". Which means
>>> that deleted items don't really do much for that part of the system.
> 
> It sounds like this is getting close to the situation that caused me to
> come up with transform-ids in TT.  i.e., some paths exist only in the
> old, some only in the new, so you can't use paths as an identifier.  But
> you can't use file-ids as identifiers, because they're not all versioned.
> 
> Aaron

I'm liking Robert's proposal more, the more I think about it.

Dirstate is specifically structured as:

info in current => [info in parents]

So if the path doesn't exist in current, then it goes to the end, where
we have a list of empty 'info in current' records, and all of the parent
entries. The '=>' map is by file_id, so if there was a rename from
parent to current, the parent path will be different than the current
path, but the file ids will be the same.

But the most important piece that indicates whether a path is versioned
in the current inventory is just if there is a file_id associated with it.

My concern about Robert setting empty paths for unversioned (and
deleted?) files is that we probably need a break in-between, since the
Root path also has an empty path. Or we just always have a Root path,
and any paths beyond the first that are empty must be unversioned....

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060912/3bbc763c/attachment.pgp 


More information about the bazaar mailing list