[Top][All Lists]
[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