Hi,
Am Dienstag, 2. Mai 2006 13:49 schrieb Ludovic Courtès:
>
> Obviously, the main issue would be portability of the diff methods
> used. Each diff method would have to be named and described. Such
> meta-data could go, for instance, in the `{arch}' sub-directory of a
> tree:
>
> {arch}
>
> +-- =diff-methods
>
> +-- line-oriented
>
> | +-- diff
> | +-- diff3
> | `-- patch
>
> +-- token-replacement
>
> | +-- diff
> | `-- patch
>
> `-- xml
>
> +-- diff
> `-- patch
>
>
> The files `diff', `diff3' and `patch' would describe command-lines to be
> used to perform the corresponding operations for the diff method at
> hand.
an obvious problem with that approach is that executable content (i. e.
"command-lines") is automatically downloaded and executed on a simple
checkout operation. That's a big security risk and something I wouldn't
want to see in any RCS.
The other obvious problem is that the casual user may have to install
a large bunch of diff + patch tools just in order to view the current state
of some piece of software in an arch repository, which I find undesirable.
> This kind of feature would be nice, but it is unclear how much could be
> gained from this.
I agree such functionality would be nice. Two obvious advantages would be
* possibly more efficient diffs (i. e. smaller deltas)
* improved merge capabilities that deal with a file not just as an
ordered collection of lines of text but rely on the *semantics* of
these text lines
The former has often been discarded as "not important" on this list
(in various discussions), and in this case I tend to agree.
Therefore I'd suggest to include only two very simple diff/patch algorithms
in arch (one for text, one for binaries) that are used for creating
and replaying the revisions that make up an arch repository. Basically,
that's what we have today, although the binary "diff" could be improved.
On that solid foundation it would be possible to build improved
merge-support with clever diff/patch algorithms relying on the semantics
of the files. Support for these improved merge algorithms would be
a purely local issue, and therefore would not suffer from the problems
described above.
Bye,
Peter
--
Peter Conrad Tel: +49 6102 / 80 99 072
[ t]ivano Software GmbH Fax: +49 6102 / 80 99 071
Bahnhofstr. 18 http://www.tivano.de/
63263 Neu-Isenburg
Germany
_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://lists.gnu.org/mailman/listinfo/gnu-arch-users
GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/
