gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: [BUG] Re: False "binary" files


From: Miles Bader
Subject: Re: [Gnu-arch-users] Re: [BUG] Re: False "binary" files
Date: Mon, 14 Feb 2005 10:39:36 +0900

On Sun, 13 Feb 2005 20:10:49 -0500, Stefan Monnier
<address@hidden> wrote:
> > 1) Extend diffutils to handle various cases like this and standartize
> >    use of these enhanced diffutils.
> > 2) Implement support for multiple diffutils in tla, where the archive
> >    would somehow state which ones it needs and which ones should be used
> >    for different files in the archive.
> 
> Nb 2 is clearly the most flexible option.
> It could even be used internally to replace the .arch-ids subdirectory with
> a .arch-ids file with a specialized merge/diff algorithm (which would mirror
> the order-agnostic diff/merge currently used for directories).

Yes, that would be nice.

It seems that there are two slightly different things: (a) alternative
_standard_ diff/patch algorithms, such as a .arch-ids file differ
(almost trivial of course), and (b) support for user-defined
diff/patch algorithms, e.g. with scripts embedded directly in the tree
or something.

(a) obviously suffers from the problem of supporting old users, maybe
it would need an archive rev because of that; (b) suffers from the
similar problem of making sure users have all needed components to use
a customized tree and also has security worries if any executable
scripts end up in archives.

Because of the security probs, maybe it's just not reasonable to ever
allow any branches to be "self-extensible", and instead, (b) should
just rely on a flexible but declarative extension mechanism.

E.g., maybe a changeset could directly specify a list of named
diff/patch extensions it needs, and tla would (1) check to make sure
the user had those extensions installed, aborting with a descriptive
error if not, and otherwise (2) when doing diffing or patching, would
call a user-hook in appropriate places with the name of the diff/patch
extension and files to diff or patch.

So a changeset might have a file called "=diff-patch-extensions",
containing e.g. a list of diff/patch-extension-name / filename-regexp
pairs:

    arch-ids     .arch-ids
    unzip-first  .*\.gz

or something like that.

[A possible point:  the list of extensions needs to be in the {arch}
dir, so that the user can modify it, and changeset-creation can find
it, but it seems like there also needs to be another copy in the
top-level changeset dir so that its contents can be found _before_
changeset application.]

Hmmm, ideas?

-Miles
-- 
Do not taunt Happy Fun Ball.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]