Re: [Monotone-devel] Kicking around ideas

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> The "user" is in this case my GUI which does lazy expansion of the
> inventory tree. Imagine a situation where a file system watcher notices
> "source has been removed from disk". This action would trigger a re-read
> of the inventory, restricted to the "source" path. 

This is the problem.

Suppose the file structure is:

dir_1/source/file_1
dir_1/source/file_2

and the user does:

mtn mv dir_1/source dir_1/target

The watcher should notice "dir_1 has been changed" and do "mtn
automate inventory dir_1"

Or notice that "source" is a directory, and do "mtn automate inventory
`cd source/..; pwd'"

Then the output will be perfectly understandable.

In addition, the inventory output is only confusing if the user uses
"--bookkeep-only"; then they get what they deserve :). Actually, in
that case, the filesystem watcher should not be notified, so it
shouldn't be a problem.

> a) would take too long for huge workspaces, and

Right. But going up one layer of directory should be acceptable. And
renaming directories should be rare.

I guess if "source" is at the top of the tree, then "source/.." is the
whole workspace. But renaming at that level should be even rarer.

> b) would make me having to rebuild the whole inventory tree in the
> GUI and thus loose the user's focus, which could be still in some
> completly different context.

I don't follow this. If by "focus" you mean the typical GUI notion of
"which window receives input events", I don't see why that would be
lost.

> So no, I need exact output for a restriction on any known node.

In this case, that is "dir_1".

Or, since it is a tool, it can figure out confusing to people but well
documented inventory output. We probably need to improve the
documentation for this case.

Or, it can figure out that it needs to do "mtn automate inventory
source" _and_ "mtn automate inventory target". And it should handle
errors from mtn like "restriction includes unknown path 'dir_a'".

On the other hand, it does make sense to try to improve the inventory
output if that would make it easier for the tool, as long as it
doesn't break the non-restricted use.

But I don't have a clear statement of a precise use case that you are
trying to improve, and what is wrong with it.

I've looked thru the output in tests/automate_inventory_restricted for
the rename directory case (that I recently added on the main branch),
and I don't see why a tool would have trouble using it. 

The case where the user used "--bookkeeping-only" is odd, but I don't
think that should bother this tool.

-- 
-- Stephe