Re: [Gnu-arch-users] from a file's point of view

[Tobias C. Rittweiler]

For all those who can't imagine anything under interpolated diffs, see
the last paragraph at
http://lists.fifthvision.net/mailman/htdig/arch-users/2003-August/030507.html


On Monday, September 22, 2003 at 7:39:23 PM, 
    Tom Lord <address@hidden> wrote:

>         Me:
>
>         > [Search changesets.  Perhaps build an index to them.]
> [...]
> I suggested just building a little index for these queries.   A
> slightly fancy way to build such an index, having the side effect of
> _also_ optimizing for very fast `annotate' output, was mentioned on
> the list a few weeks ago.   The idea, as you may remember, is to
> modify `patch(1)' so that it can read and write files with
> interpolated diffs rather than overwriting files with patched
> contents. [...]

interpolated diff: A hack on patch or a new toolset?
====================================================

IIRC, you were unsure---when you brought up this interpolated diff the
first time---whether or not it would be wiser to hack on patch or to
create new tools. I'm in favor of the latter, with the following
reasoning:

A `diff file' is a file produced by `diff(1)' and it describes the
changes between two files compared line by line. `patch(1)' is the
corresponding "reverse" program, which creates a file2 out of file1
when a `diff file' between these two files is provided.

The output file generated by your interpolated diff mode hack will /not/
be a file describing line-by-line changes between two files. Thus we may
not speak of a `diff file', and, as a further consequence, we may not
(or should not) use a `diff(1)' respectively a `patch(1)' program,
because it'd end up in a misuse.

That's why I propose two new programms. I think the output of your
interpolated diff mode can be seen as a `history file', with the ending
`.hist'. As a `diff(1)' program creates a `.diff' file, we should have
an analogy here: the `.hist' file should be created by a program
`hist'.
The counterpart to `patch(1)' could be `pick(1)', as we're picking
various, particular information out of a `history file'.

Example of Use:

  $ hist --id "cat-bra-ver--base-0" -- /dev/null file-base0 > file.hist

Where `file-base0' is a file of revision cat-bra-ver--base-0. We
explicitely pass an --id, because we want to create a generic
tool(set) and not something cutted down to arch only.
  
  $ hist --output file.hist --id "cat-bra-ver--patch-1" -- \
        file.hist file-patch1

This will update file.hist (--output is equal to the -o option of
`sort(1)') with the modifications of file-patch1.

  $ pick --ids < file.hist
  cat-bra-ver--base-0
  cat-bra-ver--patch-1

So this would tell by which revisions a file `file' is modified.

  $ pick --content --id "cat-bra-ver--base0" < file.hist
  <content of file `file' in revision cat-bra-ver--base0>

Implementing that --content thingy is not that trivial, especially in
comparasion to the --ids thingy (which does essentially nothing more
than sed -e 's/^v* \(.*\) v*$/\1/g' file.hist | sort | uniq).


-- tcr (address@hidden)  ``Ho chresim'eidos uch ho poll'eidos sophos''