Hi,
Peter Conrad <[EMAIL PROTECTED]> 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.
_______________________________________________
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/
