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

[Stefan Monnier]

> (a) obviously suffers from the problem of supporting old users, maybe
> it would need an archive rev because of that;

Yes, I'm assuming we're going to change the archive format.  Maybe it can be
done in a backward compatible way, but I'm not sure it's worth the trouble.

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

>From a revision-control point of view, putting the diff/patch code in the
same branch as the project sounds like bad practice.  I suspect security
problems would be dwarfed by more immediate concerns.  E.g. it would
probably also suffer from bootstrapping problems (how do you do the first
check out?).

> and instead, (b) should just rely on a flexible but declarative
> extension mechanism.

I'd use an indirection: changesets and such would specify "diff/patch/merge"
names, and then users ~/.arch-params would map those names to actual
programs.  It seems safer, more flexible, ...

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

Since two files with the same extension might use different diff/patch
algorithm (typically if they're in different subdirectories), the changeset
format would probably be better off listing the files themselves.

A regexp table would be in order for .arch-inventory or some such in order
to determine which algo to use when building the changeset, tho.


        Stefan