Re: [Monotone-devel] Kicking around ideas

[Thomas Keller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen Leake schrieb:
> 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.

Ok, this was a bad example. You're right of course that a filesystem
watcher has actually to trigger a reload of the parent node, not the
added/removed/whatever node itself.

> 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.

Imagine an konqueror/explorer-like application with a folder tree on the
left and a file list on the right. The tree on the left displays a
certain state, i.e. shows all directories as expanded the user clicked.
The file list on the right lists the contents of the _active_ folder on
the left and may have a scroll offset and/or individual selection.

Since the filesystem watcher updates to the model do happen
autonomously, I want to ensure that these view states are preserved as
greatly as possible, but this also means that I can only do very
restrictive querying and updates to the underlying model.

>> 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. 

I'm pretty confident that the current restricted output is ok for my
application and doesn't harm any other existing implementation either ;)

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

I don't think --bookkeep-only is our problem, more f.e. IDEs like
Eclipse which may not be mtn-aware when they refactor / move code. So
you end up having absolutely no sync between the filesystem and the
workspace manifest.

Thomas.

- --
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHlz8laf7NlBYNEJIRAhsoAJ0YuNlM7LAh8wmbiSsqkto3d6SAGwCbBDA8
HUkIiMwMf69aOxyTPq3gUOg=
=i9lF
-----END PGP SIGNATURE-----