Bruce Stephens <[EMAIL PROTECTED]> writes:
> Wim Oudshoorn <[EMAIL PROTECTED]> writes:
>
>> Bruce Stephens <[EMAIL PROTECTED]> writes:
>
> [...]
>
>>> "monotone ls known <file>" will either print out just <file>, or
>>> print nothing (if the file exists but isn't tracked), or print an
>>> error (I presume using cerr) and return an error status. So that's
>>> not very clean, but it seems OK to me.
>>
>> As described somewhere else that is not really ideal, and very slow.
>
> I wonder why it's slow.
>
> I mean, it's inevitably going to be slower than one would like,
> because monotone is a big program, and probably does a fair bit of
> work regardless of what you want. But it probably ought just to be
> getting the current manifest and looking for the name in that, so that
> shouldn't be *that* costly, even though it's probably building up lots
> of data structures that aren't necessary for this specific operation.
I don't know why it is slow, but
$ time monotone ls known Monotone.pm
Monotone.pm
real 0m2.745s
user 0m1.845s
sys 0m0.083s
So it takes more than 2 seconds for a specific file in the root of
the project.
This is done with a hot cache, that is, I ran the above 3 times
in a row and took the last output.
Just to give an idea of the size of the project:
$ time monotone automate inventory | wc
3209 9690 181949
real 0m7.149s
user 0m3.749s
sys 0m1.128s
And this is done with monotone-0.23 on my iBook 1.2GHz PowerPC G4.
> Yes, I follow that. Maybe a restrictions variant of "automate
> inventory"? Presumably it's also useful to know if the file has been
> modified since last commit?
Yes, that would be ideal. But we need to think a little
bit about renames in this case.
Wim Oudshoorn
_______________________________________________
Monotone-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/monotone-devel
