monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Extensions to automation, again


From: Nathaniel Smith
Subject: Re: [Monotone-devel] Extensions to automation, again
Date: Wed, 18 Oct 2006 13:50:40 -0700
User-agent: Mutt/1.5.13 (2006-08-11)

On Wed, Oct 18, 2006 at 06:53:32PM +0200, Thomas Keller wrote:
> a) there is no automate diff command

Easy enough to add.  (Patches accepted, as usual.)

> So I thought it would be cool to have the following (additional)
> automate commands:
> 
> automate get_file_by_path PATH [REVISION]
>  -> returns the complete file given in path in a certain revision,
>     if the revision is omitted, this basically returns the current
>     contents of the file in the current workspace revision

As mentioned, this is just a convenience (it can't be any faster than
calling get_manifest_of and then get_file, it would just do those
same steps internally anyway), but it does seem like a convenient sort
of convenience.  ("mtn cat" does the same thing as a user-exposed
API.)

> automate get_file_type PATH [REVISION]
>  -> returns the file type binary/non-binary, again for the current
>     or any other revision

Monotone doesn't actually have any concept of "binary/non-binary".
What do you want this to return?  When you ask it for a textual diff
then it makes a guess at whether this is actually a good idea (using
some somewhat obscure and probably imperfect logic), but this is just
a heuristic that it applies on the fly.

> automate get_file_size PATH [REVISION]
>  -> returns the size in Bytes of the file in that version in history

We could store this in the db for efficient access -- it wouldn't
require any messing around with the network formats, because we
already have to reconstruct files when they enter thet database (to
check their hashes), and we could note down their size then, too.

But, if we're going to commit the design and maintainence effort to
providing a fast get_file_size command going forward, then we need to
make sure that there are real use cases to justify that.  I'm not
totally convinced yet -- are users really running diff all the time on
giant files, and then getting confused when it takes a bit for the
"busy" indicator to clear and the diff to appear?  If so, is the best
solution really to build in a heuristic that files above a certain
(hard-coded?) size are "large", and give the user an extra warning in
such cases?

(Regardless, the ability to display diffs is obviously useful even
without such warnings, so resolving this question isn't urgent until
there actually is a command to display diffs.)

-- Nathaniel

-- 
The Universe may  /  Be as large as they say
But it wouldn't be missed  /  If it didn't exist.
  -- Piet Hein




reply via email to

[Prev in Thread] Current Thread [Next in Thread]