Re: [Monotone-devel] basic_io inventory

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Stephen Leake schrieb:
>> Is there some documentation on these requirements for basic_io
>> parsers? 
>
> <snip>...
>
> Hrm... I don't see that either.

Ok. I'll write this up on the BasicIoFormalization wiki page, and
start another discussion thread.

>>>> What do you think about outputing 'none' explicitly, rather than
>>>> leaving out 'old_node' and 'new_node'? It would make the parser more
>>>> regular. But maybe there's a standard basic_io style?
>>> Well, "basic_io style" is: leave out what is already implicit =)
>> 
>> Ok. Does that extend to "leave out what the user has requested be
>> ignored" ? :)
>
> If speed is a problem for you here, do it. 

Ok.

> Certainly I do care about speed here as well, but I plan to
> implement this differently. While your proposal might make you read
> in your current test workspaces faster, even bigger workspaces would
> still need too long to be scanned at once.

Right.

> So, my proposal, or at least my planned implementation for guitone, is
> to use inotify together with restrictions. Qt provides since 4.2 a nice
> interface for this, named QFileSystemWatcher. So, I have one or more
> threads in the background which look for updates in the current
> workspace and trigger mtn automate inventory for new information on the
> fly. If a user hits commit, I already have all needed information
> available I need to actually commit all files which have changed.

That makes sense.

Emacs has a similar mechanism in its older version control interfaces
(ie for CVS); when Emacs writes a file, it checks to see if there is a
*cvs* buffer monitoring that directory, and puts an entry in that
buffer recording the fact that the file changed. So no scan of the
workspace is necessary. I'm hoping to have Emacs DVC do the same;
currently it does not.

That doesn't help if you use a shell to rename a file, etc. Hooking
into the OS is more reliable.

It also doesn't help after a 'mtn pull', of course. 

>>> Because these node numbers are completly internal. You should not rely
>>> on them having specific values, because maybe they change if you
>>> change the platform (32bit <> 64bit) (this is just a guess). Anyways,
>>> why should you even bother? They're completly uninteresting =)
>> 
>> If they are truly uninteresting, they don't need to be in the output
>> in the first place. 
>
> Their only purpose here is rename matching (and currently determination
> of adds and drops). Their actual value for a single node itself is
> meaningless.

Ok. So if we add rename, add and drop status to the automate inventory
output, we don't need to output the node ids.

-- 
-- Stephe