[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] from a file's point of view
From: |
Tobias C. Rittweiler |
Subject: |
Re: [Gnu-arch-users] from a file's point of view |
Date: |
Tue, 23 Sep 2003 20:31:02 +0200 |
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''
Re: [Gnu-arch-users] from a file's point of view, Bruce Stephens, 2003/09/22
Re: [Gnu-arch-users] from a file's point of view, Tom Lord, 2003/09/22