Re: [Gnu-arch-users] Type-specific diff & patch

[Ludovic Courtès]

Hi,

Peter Conrad <address@hidden> writes:

> 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.

There are two "solutions" I can think of:

 1. Arch gets the closest cached revision (no diff/patch needed here)
    and lets you inspect the diff/patch command lines _if_ specific
    diff/patch tools and command-lines are specified.

 2. Specifying command-line tools is not possible at all.  This has to
    be done locally by the user itself in their `.arch-params'.
    Additionally, Arch could hardwire default command-lines for some
    common tools.

Looks like (2) would be the simplest solution.

> 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.

Well, we'd have to weight the pros and cons, but I think the final
decision should be left to the user.

> 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.

Yeah, possibly, although one could also find use cases where using
specific diff/patch tools would yield noticeable bandwidth/storage
improvements.

> 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.

As Tom would say, this is not "semantic diff", but rather "syntactic" or
"structural" diff.  It might indeed help improve merging, as evidenced
by the token-replacement diff/patch tools in Darcs.

Thanks,
Ludovic.