[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Kicking around ideas
Re: [Monotone-devel] Kicking around ideas
Wed, 23 Jan 2008 14:20:37 +0100
Thunderbird 126.96.36.199 (X11/20070801)
-----BEGIN PGP SIGNED MESSAGE-----
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:
> 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
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
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
-----END PGP SIGNATURE-----
Re: [Monotone-devel] Kicking around ideas, Stephen Leake, 2008/01/22
Re: [Monotone-devel] Kicking around ideas, Thomas Keller, 2008/01/22