monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] mtn cat vs. mtn automate get_file


From: Nathaniel Smith
Subject: Re: [Monotone-devel] mtn cat vs. mtn automate get_file
Date: Sat, 18 Nov 2006 14:24:39 -0800
User-agent: Mutt/1.5.13 (2006-08-11)

On Sat, Nov 18, 2006 at 02:59:52PM +0100, Thomas Keller wrote:
> c) 'mtn cat -r <base> <filename>' returns the original file content or 
> nothing if the file was unknown in this revision, that is the file is 
> new (FIXME: I have no information if the content is binary at this 
> point, I need to trust on the mtn:manual_merge attribute on the file 
> which can easily be removed by hand - so actually I don't like to trust 
> on that one too much)

Does it matter?  If the file can be displayed reasonably as text, then
you might as well do so; if it can't, then it doesn't matter what the
user says, you can't show it as text.  I think a heuristic based on
the file contents should be sufficient here... (this is exactly what
diff(1) does, for that matter).

> In the end all these information should be nicely put together in a view 
> which shows the complete file and the changed lines with red and green 
> background (maybe even a split view with synchronized scrolling, but 
> this is a long way down the road...).

xxdiff has C++/Qt code for parsing patching patch files and doing such
side-scrolling displays; possibly some could be stolen and adapted.

> Anyways, it should be obvious that I need to break with my work in c), 
> because mtn cat is not yet available via automate. There is mtn automate 
> get_file, but this needs a file ID. Where to get this file ID? Either 
> from the manifest of the parent or by calling get_revision. But yes, I 
> currently do not use this at all, and I'd need to retrieve the complete 
> manifest or revision just to get a single fileid... not the best way IMHO.

For the record, you won't get any efficiency gain by not loading the
manifest -- monotone will just have to load the manifest internally
anyway.

> So there are several possibilities which could work for me (and others 
> in the same situation):
> 
> a) make mtn cat available over mtn automate, maybe rename it and remove 
> get_file; expand the "automate cat" command to also accept fileid's with 
> one of these nice new options available there.

'cat' seems like a fundamental enough operation that we might as well
just provide it as a primitive.  ('get_file' is a primitive too, in a
difference sense.)  Perhaps get_file_of, by analogy to
get_manifest_of?

-- Nathaniel

-- 
Damn the Solar System.  Bad light; planets too distant; pestered with
comets; feeble contrivance; could make a better one myself.
  -- Lord Jeffrey




reply via email to

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